From nobody Thu May 4 20:34:34 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C226B127078; Thu, 4 May 2017 20:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee To: Cc: manet@ietf.org, ietf@ietf.org, draft-ietf-manet-olsrv2-multipath.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149395525273.6861.14988459288524802803@ietfa.amsl.com> Date: Thu, 04 May 2017 20:34:12 -0700 Archived-At: Subject: [manet] Genart last call review of draft-ietf-manet-olsrv2-multipath-12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 03:34:13 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-manet-olsrv2-multipath-12 Reviewer: Peter Yee Review Date: 2017-05-04 IETF LC End Date: 2017-05-04 IESG Telechat date: 2017-05-11 Summary: This Experimental draft is ready with nits. The draft specifies an interoperable, multipath extension to OLSRv2. Other than the nits, I find the draft to be a fine experiment to help determine how well OLSRv2 can be improved by allowing multiple, disjoint paths between nodes. Major issues: None Minor issues: None Nits/editorial comments: General: I'd suggesting changing occurrences of "multi-path" to "multipath" for consistency with prior works, including the primary work by the same authors [ADHOC11]. Consider changing "Multi-path Dijkstra Algorithm" to "multipath Dijkstra's algorithm". In any case, use the name consistently - it varies throughout the document. Change "Round-Robin" (and variations in capitalization) to "round-robin" throughout the document. Stick to one capitalization form for "MP-OLSRv2 Routing Process". Section 10 was not reviewed because it contains RFC Editor instructions to delete it. Specific: Page 3, section 1, 2nd paragraph, last sentence: append a comma after "reliability". Page 3, section 1, 3rd paragraph, 1st sentence: delete the leading "The". Insert "the "before "Multi-path Dijkstra". [See general comment about hyphenating multi-path]. Page, section 1.1, 4th bullet item: delete the second "the". Page 4, 1st full paragraph, 2nd sentence: change "Standard" to "Standards". Delete comma after "Track". Page 4, 2nd bullet item, 3rd sentence: change "setting" to "applying". (This is an aesthetics comment - take it or leave it.) Page 4, 4th bullet item, 3rd sentence: expand acronym "MPR" on first usage and in general do so for all acronyms that would not be immediately obvious to a large audience. Page 4, 5th bullet item, 4th sentence: delete "the" before "loose". Page 4, 6th bullet, 3rd sentence: append "parts" after "following". Page 6, section 3, 1st paragraph, 2nd sentence: delete both commas. Page 6, section 3, 2nd paragraph, 2nd sentence: delete "the" before "information". Insert "a" before "DiffServ". Change "Code Point" to codepoint. [RFC 2474 only refers to these a "Code Point" in specific names, but otherwise uses the generic form "codepoint". Page 6, section 3, 3rd paragraph, 1st sentence: insert "a" before "new". Page 6, section 3, 3rd paragraph, 3rd sentence: insert "the" before "loose". Page 7, section 4, 3rd bullet item: insert "the" before "shortest". Page 8, partial paragraph at top: change "as" to "using the". Page 8, section 5.1, SR_TC_INTERVAL definition: change "a" to "an". Page 8, section 5.1, SR_HOLD_TIME_MULTIPLIER definition: change "minimal" to "minimum". Change "a" to "an" unless that acronym is spoken like a word and not spelled out. Page 8, section 6, 2nd sentence: delete comma after "datagram". Page 9, section 6.1, 1st sentence: insert "the" before "MP-OLSRv2". Page 9, section 6.1.1, 1st paragraph, 1st sentence: change "signalling" to "signaling". [Other words in the document tend to suggest that the American spellings are being used rather than British forms.] Page 9, section 6.2.1, 1st sentence: insert "the" before "loose". Page 10, section 7.1, 1st paragraph, 2nd sentence: delete the comma. Insert "the" before each of "MP-OLSRv2" and "OLSRv2". Page 11, section 8, 2nd sentence: insert "the" before "topology". Page 11, section 8, 3rd sentence: change "between" to "from the". Page 11, section 8.1, 2nd paragraph, 2nd sentence: insert "the" before "SR_TC_INTERVAL". Page 11, section 8.1, 2nd paragraph, 3rd sentence: delete "The". Page 11, section 8.1, 2nd paragraph, 5th sentence: insert "the" before "SOURCE_ROUTE TLV". Page 12, section 8.3, 1st bullet item: change "possiblity" to "possibility". Page 12, section 8.3, 2nd bullet item, 2nd sentence: perhaps change "Or else" to "Otherwise". Page 12, section 8.4, 1st paragraph: insert "a" before "DiffServ". Change "Code Point" to "codepoint". Page 13, 1st paragraph, last sentence: insert "the" before "OLSRv2". Page 13, 3rd paragraph, 2nd sentence: insert "the" before "format". Page 13, the paragraph: insert "the" before "following". Page 13, last paragraph, 2nd sentence: insert "the" before "outer" and "source". Page 14, section 8.5.1, 1st paragraph after the 1st set of bullet items: insert "the" before "SR-OLSRv2". Page 14, section 8.5.1, 2nd paragraph after the 1st set of bullet items, 3rd sentence: insert "the" before "OLSRv2". Page 14, section 8.5.1, 2nd paragraph after the 1st set of bullet items, 4th sentence: change "much" to "many". Page 14, section 8.5.1, 3rd paragraph after the 1st set of bullet items: shouldn't this be up to "NUMBER_OF_PATHS" rather than always "NUMBER_OF_PATHS" paths that are created? Meaning that it's possible the algorithm will not have sufficient disjoint paths to choose from in some (probably degenerate) cases? Delete the second comma in the sentence. Page 14, section 8.5.1, 2nd set of bullet items, 2nd bullet item, 1st sentence: change "A" to "An". Page 14, section 8.5.1, 2nd set of bullet items, 2nd bullet item, 2nd sentence: insert "the" before "Multi-path". Page 14, section 8.5.2, 1st sentence: insert "the" before "Multi-path". Page 15, 1st full paragraph, 1st sentence: change the second occurrence of "Dijkstra" to "Dijkstra's". Page 15, 2nd bullet item, 2nd sentence: change "is" to "does". Page 15, 1st paragraph after bullet items, 3rd sentence: change "vetex" to "vertex". Page 15, 1st paragraph after figure, 2nd sentence: change "of" to "for". Page 16, 1st sentence: change "Dijkstra" to "Dijkstra's". Page 16, 1st paragraph after numbered list: insert "the" before "Multi-path". Page 16, section 8.6, 1st paragraph, last sentence: insert "whether" before "the set". Page 16, section 9, 1st sentence: change "guideline" to "guidelines". Page 16, section 9, 2nd sentence: delete the comma after "certain". Page 17, "if id X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18333126CC7; Mon, 8 May 2017 16:28:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-manet-olsrv2-multipath@ietf.org, aretana@cisco.com, Stan Ratliff , manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> Date: Mon, 08 May 2017 16:28:11 -0700 Archived-At: Subject: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 23:28:11 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-manet-olsrv2-multipath-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The following text in section 4 seems to indicate that scheduling is done on a per-packet basis: "When there is a datagram to be sent to a destination, the source router acquires a path from the Multi-path Routing Set (MAY be Round-Robin, or other scheduling algorithms)." This seems not appropriate as e.g. TCP packets routed on links with largely different delays may suffer performance. ECMP usually hashes the 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and routes all packets belonging to the same flow on the same route. I recommend to apply the same here. Also related is this text in section 8.4 that should explain Round-Robin on a per flow basis instead. Further this should only be an example scheduling alogirthm while text belong seems to assume that Round-Robin is always used. "If a matching Multi-path Routing Tuple is obtained, the Path Tuples of the Multi-path Routing Tuple are applied to the datagrams using Round-robin scheduling. For example, there are 2 path Tuples (Path-1, Path-2) for destination router D. A series of datagrams (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc. Other path scheduling mechanisms are also possible and will not impact the interoperability of different implementations." Related is this text in section 8.4.: "If datagrams without source routing header need to be forwarded using multiple paths (for example, based on the information of DiffServ Code Point [RFC2474])" RFC2474 does not specify any application requirements on multipath use and as such the DiffServe field should not be used to determine if the flow can be routed on multiple paths. The ability to profit from multipath routing depends not only on the application and protocols used but also on the characteristics of the multipath link(s); so it's hard to make any implicit assumptions here. However, if routing would only be recommended on a per-flow basis this problem does not occur and the brackets above could be remove. Further, if routed on a per flow basis would be done, DiffServ could actually be used to decide which path to use, if e.g. one path has a lower delay, but that seem to need further discussion as well. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor comments/questions: 1) section 8.4: this sentence is not clear: "It is RECOMMENDED to use MTU sizes considering the source routing header to avoid fragmentation." MAYBE "It is NOT RECOMMENDED to fragment the IP packet if the packet with the source routing header would exceed the minimum MTU along the path. In this case source routing and therefore the additional path calculated by MP-OLSRv2 SHOULD NOT be used." 2) section 9: "For IPv6 networks, it MUST be set to 0, i.e., no constraint on maximum number of hops." Why is that? 3) Not sure why section 12.1. is there? Can this be removed? From nobody Tue May 9 01:47:31 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAEE129B4B; Tue, 9 May 2017 01:47:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Zhen Cao To: Cc: manet@ietf.org, ietf@ietf.org, draft-ietf-manet-olsrv2-multipath.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149431964538.10555.11264594833770083998@ietfa.amsl.com> Date: Tue, 09 May 2017 01:47:25 -0700 Archived-At: Subject: [manet] Intdir telechat review of draft-ietf-manet-olsrv2-multipath-12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 08:47:25 -0000 Reviewer: Zhen Cao Review result: Ready with Issues I am an assigned INT directorate reviewer for this draft. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherds should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details of the INT directorate, see . I believe this document is ready to publish almost as it is. One issue I found during my review lies in Sec. 8.4 where IPv4 loose source routing being discussed. To avoid unnecessary fragmentation, I am suggesting the following wording change: S/ If the length of the path (n) is greater than MAX_SRC_HOPS (Section 5), only the "key" routers in the path are kept... / If the length of the path (n) is greater than MAX_SRC_HOPS (Section 5), or the adding of source routing header exceeds the path MTU, only the "key" routers in the path are kept... Cheers, Zhen From nobody Tue May 9 03:13:46 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF75129BA3; Tue, 9 May 2017 03:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxeZOp4pJJK4; Tue, 9 May 2017 03:13:35 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52701200F3; Tue, 9 May 2017 03:13:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,313,1491260400"; d="scan'208";a="181637638" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 09 May 2017 11:13:31 +0100 X-IronPort-AV: E=Sophos;i="5.38,313,1491260400"; d="scan'208";a="170502794" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 09 May 2017 11:13:12 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.172]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Tue, 9 May 2017 11:13:12 +0100 From: "Dearlove, Christopher (UK)" To: "ietf@ietf.org" , IETF-Announce CC: "manet@ietf.org" , "draft-ietf-manet-olsrv2-multipath@ietf.org" , "manet-chairs@ietf.org" Thread-Topic: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC Thread-Index: AQHSuiCA8lo3GCHD2k6nFUb/R8wgmaHr37cA Date: Tue, 9 May 2017 10:13:11 +0000 Message-ID: References: <149272508088.22258.8263343290438640855.idtracker@ietfa.amsl.com> In-Reply-To: <149272508088.22258.8263343290438640855.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 10:13:37 -0000 A few comments on this draft. IPv6 specifies complete source routing. But this specification can only con= sider what happens within the MANET. So for a packet from somewhere in the = MANET to somewhere well outside the MANET, the packet must be source routed= to the gateway between MANET and rest of Internet, and not source routed a= fter that. This I think should be explicitly mentioned. Whether that is con= sidered compliant with IPv6 I leave to others. 7.1 SR_addr would better say "originator" address rather than "network" add= ress. (That makes it an address without a netmask, see RFC 7181.) 8.1 This is suggesting creating TC messages that have on neighbour addresse= s but have only a SOURCE_ROUTE TLV. This is not the design I would have sug= gested as consistent with how I would expect an extension to OLSRv2 to do t= hings. We need to consider two kinds of routers: those sending TC messages = anyway, those that (other than this extension) do not. In the former case y= ou could just add the SOURCE_ROUTE TLV to those TC messages it sends. Then = that information is maintained up to date. Routers that don't usually send = TC messages could send TC messages with just that TLV. But then there's an = issue over validity time. A parameter SR_HOLD_TIME_MULTIPLIER is introduced= . There's no need for that - you can simply incorporate that into the valid= ity time recorded in the message. That avoids a need to handle the two case= s of routers differently. There is then an oddity that you get some routers= sending TC messages with normal validity times and addresses, and some tha= t can be sent less frequently with no addresses and longer validity times. = But that's suspect - note that it's not done in OLSRv2 for attached network= s (another reason to send TC messages although no neighbours need reporting= ). That's because longer intervals make reacting to new routers joining (an= d network reassembly after fragmentation) slow. Rather a better design woul= d simply be to add SOURCE_ROUTE TLV to normal TC messages. When sending TC = messages for just that reason, that could be just the usual case, but you c= ould allow as an option in this case to send less frequently with validity = time increased accordingly. When not using that option, once a router needs= to send a TC message, it could then decide to report neighbours, increasin= g the topology distributed and allowing more routes, this also being an opt= ion. 8.3 second bullet. You should here (and possibly elsewhere) exclude routers= with routing willingness zero. 8.3 there seems to be an inconsistency. When operating proactively and no m= ultiple routes, drop the packet, but reactively use standard routing. The l= atter seems more appropriate in the former case also. 9 CUTOFF_RATIO. Insists of strictly, but as defined earlier, may be >=3D 1`. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: =A0+44 3300 467500 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of The IESG Sent: 20 April 2017 22:51 To: IETF-Announce Cc: manet@ietf.org; draft-ietf-manet-olsrv2-multipath@ietf.org; manet-chair= s@ietf.org Subject: [manet] Last Call: (Mul= ti-path Extension for the Optimized Link State Routing Protocol version 2 (= OLSRv2)) to Experimental RFC ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final= comments on this action. Please send substantive comments to the ietf@ietf= .org mailing lists by 2017-05-04. Exceptionally, comments may be sent to ie= sg@ietf.org instead. In either case, please retain the beginning of the Sub= ject line to allow automated sorting. Abstract This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From nobody Tue May 9 15:49:00 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239221294E9; Tue, 9 May 2017 15:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TTvAtv8wAYd; Tue, 9 May 2017 15:48:49 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACB3124BFA; Tue, 9 May 2017 15:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494370125; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=7754; bh=cJ5Tp6yh2KVb3tuApafOh15RjUTU1NpII5ipqqBbTdk=; b=DZoaVHppMuG1066LTGpbjTfpGsKUtwSI7+swjYtu9aATi+uk4otW42vkWqlr9Axo X69aeJsJ/jGGd2e8oPpAwZzWXl9/XYezOhHve04B7hL+oKeM6lVr4siFpwGK45RVPJW EOu2HWtmhscnYRcGJGB4nEYXBhvaigWSi5bKXCDU= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494370125111762.8919372899151; Tue, 9 May 2017 15:48:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jiazi Yi In-Reply-To: Date: Wed, 10 May 2017 00:48:42 +0200 Cc: "ietf@ietf.org" , IETF-Announce , "manet@ietf.org" , "draft-ietf-manet-olsrv2-multipath@ietf.org" , "manet-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9096512E-3473-473A-B6F1-37CBDD82A0F4@jiaziyi.com> References: <149272508088.22258.8263343290438640855.idtracker@ietfa.amsl.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:48:51 -0000 Hi Chris,=20 Thanks a lot for the comments! Please check our reply inline:=20 > On 9 May 2017, at 12:13, Dearlove, Christopher (UK) = wrote: >=20 > A few comments on this draft. >=20 > IPv6 specifies complete source routing. But this specification can = only consider what happens within the MANET. So for a packet from = somewhere in the MANET to somewhere well outside the MANET, the packet = must be source routed to the gateway between MANET and rest of Internet, = and not source routed after that. This I think should be explicitly = mentioned. Whether that is considered compliant with IPv6 I leave to = others. Good point. We added some text at the end of section 8.4" Datagram = Processing at the MP-OLSRv2 Originator" >=20 > 7.1 SR_addr would better say "originator" address rather than = "network" address. (That makes it an address without a netmask, see RFC = 7181.) fixed.=20 >=20 > 8.1 This is suggesting creating TC messages that have on neighbour = addresses but have only a SOURCE_ROUTE TLV. This is not the design I = would have suggested as consistent with how I would expect an extension = to OLSRv2 to do things. We need to consider two kinds of routers: those = sending TC messages anyway, those that (other than this extension) do = not. In the former case you could just add the SOURCE_ROUTE TLV to those = TC messages it sends. Then that information is maintained up to date. = Routers that don't usually send TC messages could send TC messages with = just that TLV. But then there's an issue over validity time. A parameter = SR_HOLD_TIME_MULTIPLIER is introduced. There's no need for that - you = can simply incorporate that into the validity time recorded in the = message. That avoids a need to handle the two cases of routers = differently. There is then an oddity that you get some routers sending = TC messages with normal validity times and addresses, and some that can = be sent less frequently with no addresses and longer validity times. But = that's suspect - note that it's not done in OLSRv2 for attached networks = (another reason to send TC messages although no neighbours need = reporting). That's because longer intervals make reacting to new routers = joining (and network reassembly after fragmentation) slow. > Rather a better design would simply be to add SOURCE_ROUTE TLV to = normal TC messages. When sending TC messages for just that reason, that = could be just the usual case, but you could allow as an option in this = case to send less frequently with validity time increased accordingly. = When not using that option, once a router needs to send a TC message, it = could then decide to report neighbours, increasing the topology = distributed and allowing more routes, this also being an option. >=20 IIRC, we had a long discussion on this issue and produced the current = text.=20 The purpose is to identify the routers that don=E2=80=99t send TC = messages but support source routing. To avoid unnecessary TC flooding, = the interval is much longer than the normal TC interval.=20 The normal TC messages (generated based on RFC7181) always have a = SOURCE_ROUTE TLV. But if we use the same validity time for both RFC7181 = normal TC processing and MP-OLSRv2 SR_ROUTE TLV processing, the valid = time in the SR-OLSRv2 Router Set would be much shorter than expected. A = possible case is that, the router stops sending normal TC messages, the = corresponding entry in the SR-OLSRv2 Router set will soon expire.=20 Therefore, I think it=E2=80=99s reasonable to make use of the = SR_HOLD_TIME_MULTIPLIER to distinguish the valid time of normal TC = message information and SR_ROUTE information.=20 > 8.3 second bullet. You should here (and possibly elsewhere) exclude = routers with routing willingness zero. >=20 > 8.3 there seems to be an inconsistency. When operating proactively and = no multiple routes, drop the packet, but reactively use standard = routing. The latter seems more appropriate in the former case also. >=20 > 9 CUTOFF_RATIO. Insists of strictly, but as defined earlier, may be >=3D= 1`. All fixed.=20 Thanks again for the valuable comments! best Jiazi >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > = __________________________________________________________________________= >=20 > T: +44 3300 467500 | E: chris.dearlove@baesystems.com >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 >=20 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of The IESG > Sent: 20 April 2017 22:51 > To: IETF-Announce > Cc: manet@ietf.org; draft-ietf-manet-olsrv2-multipath@ietf.org; = manet-chairs@ietf.org > Subject: [manet] Last Call: = (Multi-path Extension for the Optimized Link State Routing Protocol = version 2 (OLSRv2)) to Experimental RFC >=20 > ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our = organization. >=20 >=20 > The IESG has received a request from the Mobile Ad-hoc Networks WG > (manet) to consider the following document: > - 'Multi-path Extension for the Optimized Link State Routing Protocol > version 2 (OLSRv2)' > as Experimental RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits = final comments on this action. Please send substantive comments to the = ietf@ietf.org mailing lists by 2017-05-04. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the = beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document specifies a multi-path extension for the Optimized = Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > The interoperability with OLSRv2 is retained. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ >=20 > IESG discussion can be tracked via > = https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ballot/= >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 From nobody Tue May 9 15:51:34 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD56712EB78; Tue, 9 May 2017 15:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYWdEIoHXT_K; Tue, 9 May 2017 15:51:23 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1D512EB5C; Tue, 9 May 2017 15:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494370280; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=19042; bh=jAMAvCFP9ygr+RhAGwk3pmx9Feo7Tz7/J+fQuNyxH/U=; b=AJb7+dCc3JrIKKrGpuSZxgOpEyCJxrIPb8MQN/+CxOr5CS9kSIF+bpRYU0MlfU+I pCVP9A9iGRGLuoY4EHN+LfWVb7YXVGEdso523+ec4QNEbFrvbJHQtsisy4YEk5NODyx Q/82mW3gtKWkaA/f7muMGkmBHBRtY1VizjIFdmuM= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494370279951644.1858522970298; Tue, 9 May 2017 15:51:19 -0700 (PDT) From: Jiazi Yi Message-Id: <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A6816FD3-00F8-43FF-82BE-910570518A47" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 00:51:17 +0200 In-Reply-To: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> Cc: The IESG , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:51:27 -0000 --Apple-Mail=_A6816FD3-00F8-43FF-82BE-910570518A47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Mirja,=20 Thanks very much for your review and comments. Please find the reply = inline:=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > The following text in section 4 seems to indicate that scheduling is = done > on a per-packet basis: > "When there is a > datagram to be sent to a destination, the source router acquires a > path from the Multi-path Routing Set (MAY be Round-Robin, or other > scheduling algorithms)." > This seems not appropriate as e.g. TCP packets routed on links with > largely different delays may suffer performance. ECMP usually hashes = the > 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and = routes > all packets belonging to the same flow on the same route. I recommend = to > apply the same here. >=20 > Also related is this text in section 8.4 that should explain = Round-Robin > on a per flow basis instead. Further this should only be an example > scheduling alogirthm while text belong seems to assume that = Round-Robin > is always used. > "If a matching Multi-path Routing Tuple is obtained, the Path Tuples > of the Multi-path Routing Tuple are applied to the datagrams using > Round-robin scheduling. For example, there are 2 path Tuples > (Path-1, Path-2) for destination router D. A series of datagrams > (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. > Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 for > Packet 3, etc. Other path scheduling mechanisms are also possible > and will not impact the interoperability of different > implementations.=E2=80=9D In fact, the per-packet scheduling is an intentional choice because: 1. The aimed scenario is mobile ad hoc networks, which have high packet = loss by nature. One of the most important reasons is route failure due = to mobility =E2=80=94 in such case, if a per-flow scheduling is applied, = the whole flow will lost. On the other hand, if we send the packets in = disjoint paths (not necessarily equal cost), we can still make use = partial information of the flow, or even reconstruct the flow with = erasure coding. This is especially interesting for video/audio = streaming.=20 2. In such kind of lossy networks, the traditional TCP performs very = poor [1]. So as far as I know, TCP is not very popular in ad hoc = networks. On the other hand, based on our study, the multi-path routing = can actually reduce the overall jitter [2].=20 We understand your concern on this issue (and you can imagine that you = are not the first one who raises this ;). It is also something that we = want to have further experience from this *experimental* draft, as we = stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics.=20 =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath routing, = especially variable latencies. Although current experiment results show = that multipath routing can reduce the jitter in dynamic scenarios, some = transport protocols or applications may be sensitive to the datagram = re-ordering.=20 =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged. [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf = =20 [2] Multipath optimized link state routing for mobile ad hoc networks", = In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, 2011. >=20 > Related is this text in section 8.4.: > "If datagrams without source routing header need to be forwarded using > multiple paths (for example, based on the information of DiffServ > Code Point [RFC2474])" > RFC2474 does not specify any application requirements on multipath use > and as such the DiffServe field should not be used to determine if the > flow can be routed on multiple paths. The ability to profit from > multipath routing depends not only on the application and protocols = used > but also on the characteristics of the multipath link(s); so it's hard = to > make any implicit assumptions here. However, if routing would only be > recommended on a per-flow basis this problem does not occur and the > brackets above could be remove. Further, if routed on a per flow basis > would be done, DiffServ could actually be used to decide which path to > use, if e.g. one path has a lower delay, but that seem to need further > discussion as well. As we mentioned before, the multipath routing has special interests in = audio/video streaming applications. For applications that requires = strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Minor comments/questions: >=20 > 1) section 8.4: this sentence is not clear: > "It is RECOMMENDED to use MTU sizes considering the source routing > header to avoid fragmentation." > MAYBE > "It is NOT RECOMMENDED to fragment the IP packet if the packet with = the > source routing header would exceed the minimum MTU along the path. In > this case source routing and therefore the additional path calculated = by > MP-OLSRv2 SHOULD NOT be used.=E2=80=9D Fixed.=20 >=20 > 2) section 9: > "For IPv6 networks, it MUST > be set to 0, i.e., no constraint on maximum number of hops." > Why is that? Because the current RFC6554 supports only IPv6 strict source routing, we = thus need to keep all the path information in the source routing header, = in which case we don=E2=80=99t know the number of hops.=20 On the other hand, we noticed that the IPv6 segment routing header is = being discussed at 6man, we thus have the following text in the = =E2=80=9CExperiments to be conducted=E2=80=9D section: =E2=80=A2 Use of IPv6 loose source routing. In the current = specification, only strict source routing is used for IPv6 based on = [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routi= ng=E2=80=91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header is = critical, the loose source routing can be considered. >=20 > 3) Not sure why section 12.1. is there? Can this be removed? Removed.=20 Agains, we appreciate your valuable comments and hope that our reply = addresses your concern.=20 regards Jiazi >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_A6816FD3-00F8-43FF-82BE-910570518A47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Mirja, 

Thanks very much for your review and comments. = Please find the reply inline: 

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

The following text in section 4 = seems to indicate that scheduling is done
on a per-packet = basis:
"When there is a
=   datagram to be sent to a destination, the source router = acquires a
  path from the Multi-path Routing = Set (MAY be Round-Robin, or other
  scheduling = algorithms)."
This seems not appropriate as e.g. TCP = packets routed on links with
largely different delays may = suffer performance. ECMP usually hashes the
5-tuple or = 6-tuple (incl. DiffServ Codepoint) to setup state and routes
all packets belonging to the same flow on the same route. I = recommend to
apply the same here.

Also related is this text in section 8.4 that should explain = Round-Robin
on a per flow basis instead. Further this = should only be an example
scheduling alogirthm while text = belong seems to assume that Round-Robin
is always used.
"If a matching Multi-path Routing Tuple is obtained, the Path = Tuples
  of the Multi-path Routing Tuple are = applied to the datagrams using
  Round-robin = scheduling.  For example, there are 2 path Tuples
=   (Path-1, Path-2) for destination router D. A series of = datagrams
  (Packet-1, Packet-2, Packet-3, ... = etc.) are to be sent router D.
  Path-1 is then = chosen for Packet-1, Path-2 for Packet-2, Path-1 for
=   Packet 3, etc.  Other path scheduling mechanisms are = also possible
  and will not impact the = interoperability of different
=   implementations.=E2=80=9D

In fact, the per-packet scheduling is an = intentional choice because:

1. The = aimed scenario is mobile ad hoc networks, which have high packet loss by = nature. One of the most important reasons is route failure due to = mobility =E2=80=94 in such case, if a per-flow scheduling is applied, = the whole flow will lost. On the other hand, if we send the packets in = disjoint paths (not necessarily equal cost), we can still make use = partial information of the flow, or even reconstruct the flow with = erasure coding. This is especially interesting for video/audio = streaming. 

2. In such kind of = lossy networks, the traditional TCP performs very poor [1]. So as far as = I know, TCP is not very popular in ad hoc networks. On the other hand, = based on our study, the multi-path routing can actually reduce the = overall jitter [2]. 

We = understand your concern on this issue (and you can imagine that you are = not the first one who raises this ;). It is also something that we want = to have further experience from this *experimental* draft, as we stated = in the =E2=80=9Cexperiments to be conducted=E2=80=9D = section:

=E2=80=A2 Different = path-selection schedulers. By default, round-robin scheduling is used to = select a path to be used for datagrams. In some scenarios, weighted = scheduling can be considered: for example, the paths with lower = metrics (i.e., higher quality) can transfer more datagrams compared to = paths with higher = metrics. 
= =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath = routing, especially variable latencies. Although current experiment = results show that multipath routing can reduce the jitter in = dynamic scenarios, some transport protocols or applications may be = sensitive to the datagram = re-ordering. 
= =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus = encouraged.


[1] Performance = Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf 
[2] Multipath = optimized link state routing for mobile ad hoc networks", In Elsevier Ad = Hoc Journal, vol.9, n. 1, 28-47, January, 2011.


Related is this text in section 8.4.:
"If datagrams without source routing header need to be = forwarded using
  multiple paths (for example, = based on the information of DiffServ
  Code = Point [RFC2474])"
RFC2474 does not specify any application = requirements on multipath use
and as such the DiffServe = field should not be used to determine if the
flow can be = routed on multiple paths. The ability to profit from
multipath routing depends not only on the application and = protocols used
but also on the characteristics of the = multipath link(s); so it's hard to
make any implicit = assumptions here. However, if routing would only be
recommended on a per-flow basis this problem does not occur = and the
brackets above could be remove. Further, if routed = on a per flow basis
would be done, DiffServ could actually = be used to decide which path to
use, if e.g. one path has = a lower delay, but that seem to need further
discussion as = well.

As we mentioned before, the multipath routing has = special interests in audio/video streaming applications. For = applications that requires strict ordering, single path can be used. For = streaming and time-critical applications, the multi-path application = might be more interesting, which can be identified by the DiffServe = information. 



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Minor comments/questions:

1) section 8.4: this sentence is not clear:
"It is RECOMMENDED to use MTU sizes considering the source = routing
  header to avoid fragmentation."
MAYBE
"It is NOT RECOMMENDED to fragment the IP = packet if the packet with the
source routing header would =  exceed the minimum MTU along the path. In
this case = source routing and therefore the additional path calculated by
MP-OLSRv2 SHOULD NOT be = used.=E2=80=9D

Fixed. 


2)= section 9:
"For IPv6 networks, it MUST
=      be set to 0, i.e., no constraint on = maximum number of hops."
Why is that?

Because= the current RFC6554 supports only IPv6 strict source routing, we thus = need to keep all the path information in the source routing header, in = which case we don=E2=80=99t know the number of hops. 

On the other hand, we noticed that the IPv6 = segment routing header is being discussed at 6man, we thus have the = following text in the =E2=80=9CExperiments to be conducted=E2=80=9D = section:

=E2=80=A2 Use of IPv6 loose = source routing. In the current specification, only strict source routing = is used for IPv6 based on [RFC6554]. = In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routing=E2=80= =91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header = is critical, the loose source routing can be = considered.


3) Not sure why section 12.1. is there? Can = this be removed?

Removed. 

Agains, we appreciate your valuable comments and = hope that our reply addresses your concern. 

regards

Jiazi



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

= --Apple-Mail=_A6816FD3-00F8-43FF-82BE-910570518A47-- From nobody Tue May 9 15:54:27 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C3612EAE2; Tue, 9 May 2017 15:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oB-ipFGCeDN; Tue, 9 May 2017 15:54:15 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21076124B0A; Tue, 9 May 2017 15:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494370448; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=1359; bh=Bzue9mViNgdVB7Uz9WuBYlUb1OYFB5imytMOYWW0LZQ=; b=g57wIac15mW3hxxkQU3nTfe7YVFrLEtQJNnpEwu40cAaZn6lPM/p6FSgAugMJGg/ XL6Iw2vY9Tqi723KjaXF1jE/XrZ7IqYX7Ud4f4DQXyXqY5me5CCGorLTbxErnihcGyA dJWZONCmwXnGwldbip+5gGQ8GbcVsEUzKz1LltkI= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 149437044828451.717761972135236; Tue, 9 May 2017 15:54:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jiazi Yi In-Reply-To: <149431964538.10555.11264594833770083998@ietfa.amsl.com> Date: Wed, 10 May 2017 00:54:06 +0200 Cc: int-dir@ietf.org, manet@ietf.org, ietf@ietf.org, draft-ietf-manet-olsrv2-multipath.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <11D61838-1EE5-475B-BCBA-B4DC1D6C5BB4@jiaziyi.com> References: <149431964538.10555.11264594833770083998@ietfa.amsl.com> To: Zhen Cao X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Intdir telechat review of draft-ietf-manet-olsrv2-multipath-12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:54:17 -0000 Dear Zhen, Thanks very much for your review. We will update the draft based on the comments and submit a new revision. best Jiazi > On 9 May 2017, at 10:47, Zhen Cao wrote: > > Reviewer: Zhen Cao > Review result: Ready with Issues > > I am an assigned INT directorate reviewer for this draft. These > comments were written primarily for the benefit of the Internet Area > Directors. Document editors and shepherds should treat these comments > just like they would treat comments from any other IETF contributors > and resolve them along with any other Last Call comments that have > been received. For more details of the INT directorate, see > . > > I believe this document is ready to publish almost as it is. > > One issue I found during my review lies in Sec. 8.4 where IPv4 loose > source routing being discussed. To avoid unnecessary fragmentation, I > am suggesting the following wording change: > > S/ If the length of the path (n) is greater than MAX_SRC_HOPS > (Section 5), only the "key" routers in the path are kept... > / If the length of the path (n) is greater than MAX_SRC_HOPS > (Section 5), or the adding of source routing header exceeds the > path MTU, > only the "key" routers in the path are kept... > > Cheers, > Zhen > > > From nobody Tue May 9 15:56:24 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B3212EB91; Tue, 9 May 2017 15:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cGON3-7FbAd; Tue, 9 May 2017 15:56:07 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6DA12EB85; Tue, 9 May 2017 15:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494370563; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=8654; bh=nIEekBq1mpm+wA/3wpnGCkAb8jTZnnvgpEHsZL9xmXE=; b=qrnkKyr+d4UbZOd7xJrGGAA5P8bfg6uUSgUhKnpbOQXM8G3jowkAjdWR5nrP9Pnb gBo0nMvnbEBOMLhxEn02lnGXlfrj81XmVX1+x4sDUf4etffDOpn6rhaPV5O0BWA15jb zxubAMc94BglF21FkSUI1fWtuRSzrjAz09WuLqfs= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494370563128979.4849807958168; Tue, 9 May 2017 15:56:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jiazi Yi In-Reply-To: <149395525273.6861.14988459288524802803@ietfa.amsl.com> Date: Wed, 10 May 2017 00:56:00 +0200 Cc: gen-art@ietf.org, manet@ietf.org, ietf@ietf.org, draft-ietf-manet-olsrv2-multipath.all@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <82811D33-9B17-4C32-B045-D8685B9C3C58@jiaziyi.com> References: <149395525273.6861.14988459288524802803@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Genart last call review of draft-ietf-manet-olsrv2-multipath-12 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:56:10 -0000 Dear Peter, Thanks very much for the detailed comments. We have updated the draft and will make a new submission soon. cheers Jiazi > On 5 May 2017, at 05:34, Peter Yee wrote: > > Reviewer: Peter Yee > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-manet-olsrv2-multipath-12 > Reviewer: Peter Yee > Review Date: 2017-05-04 > IETF LC End Date: 2017-05-04 > IESG Telechat date: 2017-05-11 > > Summary: This Experimental draft is ready with nits. The draft > specifies an interoperable, multipath extension to OLSRv2. Other than > the nits, I find the draft to be a fine experiment to help determine > how well OLSRv2 can be improved by allowing multiple, disjoint paths > between nodes. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > General: > > I'd suggesting changing occurrences of "multi-path" to "multipath" for > consistency with prior works, including the primary work by the same > authors [ADHOC11]. > > Consider changing "Multi-path Dijkstra Algorithm" to "multipath > Dijkstra's algorithm". In any case, use the name consistently - it > varies throughout the document. > > Change "Round-Robin" (and variations in capitalization) to > "round-robin" throughout the document. > > Stick to one capitalization form for "MP-OLSRv2 Routing Process". > > Section 10 was not reviewed because it contains RFC Editor > instructions to delete it. > > Specific: > > Page 3, section 1, 2nd paragraph, last sentence: append a comma after > "reliability". > > Page 3, section 1, 3rd paragraph, 1st sentence: delete the leading > "The". Insert "the "before "Multi-path Dijkstra". [See general > comment about hyphenating multi-path]. > > Page, section 1.1, 4th bullet item: delete the second "the". > > Page 4, 1st full paragraph, 2nd sentence: change "Standard" to > "Standards". Delete comma after "Track". > > Page 4, 2nd bullet item, 3rd sentence: change "setting" to "applying". > (This is an aesthetics comment - take it or leave it.) > > Page 4, 4th bullet item, 3rd sentence: expand acronym "MPR" on first > usage and in general do so for all acronyms that would not be > immediately obvious to a large audience. > > Page 4, 5th bullet item, 4th sentence: delete "the" before "loose". > > Page 4, 6th bullet, 3rd sentence: append "parts" after "following". > > Page 6, section 3, 1st paragraph, 2nd sentence: delete both commas. > > Page 6, section 3, 2nd paragraph, 2nd sentence: delete "the" before > "information". Insert "a" before "DiffServ". Change "Code Point" to > codepoint. [RFC 2474 only refers to these a "Code Point" in specific > names, but otherwise uses the generic form "codepoint". > > Page 6, section 3, 3rd paragraph, 1st sentence: insert "a" before > "new". > > Page 6, section 3, 3rd paragraph, 3rd sentence: insert "the" before > "loose". > > Page 7, section 4, 3rd bullet item: insert "the" before "shortest". > > Page 8, partial paragraph at top: change "as" to "using the". > > Page 8, section 5.1, SR_TC_INTERVAL definition: change "a" to "an". > > Page 8, section 5.1, SR_HOLD_TIME_MULTIPLIER definition: change > "minimal" to "minimum". Change "a" to "an" unless that acronym is > spoken like a word and not spelled out. > > Page 8, section 6, 2nd sentence: delete comma after "datagram". > > Page 9, section 6.1, 1st sentence: insert "the" before "MP-OLSRv2". > > Page 9, section 6.1.1, 1st paragraph, 1st sentence: change > "signalling" to "signaling". [Other words in the document tend to > suggest that the American spellings are being used rather than British > forms.] > > Page 9, section 6.2.1, 1st sentence: insert "the" before "loose". > > Page 10, section 7.1, 1st paragraph, 2nd sentence: delete the comma. > Insert "the" before each of "MP-OLSRv2" and "OLSRv2". > > Page 11, section 8, 2nd sentence: insert "the" before "topology". > > Page 11, section 8, 3rd sentence: change "between" to "from the". > > Page 11, section 8.1, 2nd paragraph, 2nd sentence: insert "the" before > "SR_TC_INTERVAL". > > Page 11, section 8.1, 2nd paragraph, 3rd sentence: delete "The". > > Page 11, section 8.1, 2nd paragraph, 5th sentence: insert "the" before > "SOURCE_ROUTE TLV". > > Page 12, section 8.3, 1st bullet item: change "possiblity" to > "possibility". > > Page 12, section 8.3, 2nd bullet item, 2nd sentence: perhaps change > "Or else" to "Otherwise". > > Page 12, section 8.4, 1st paragraph: insert "a" before "DiffServ". > Change "Code Point" to "codepoint". > > Page 13, 1st paragraph, last sentence: insert "the" before "OLSRv2". > > Page 13, 3rd paragraph, 2nd sentence: insert "the" before "format". > > Page 13, the paragraph: insert "the" before "following". > > Page 13, last paragraph, 2nd sentence: insert "the" before "outer" and > "source". > > Page 14, section 8.5.1, 1st paragraph after the 1st set of bullet > items: insert "the" before "SR-OLSRv2". > > Page 14, section 8.5.1, 2nd paragraph after the 1st set of bullet > items, 3rd sentence: insert "the" before "OLSRv2". > > Page 14, section 8.5.1, 2nd paragraph after the 1st set of bullet > items, 4th sentence: change "much" to "many". > > Page 14, section 8.5.1, 3rd paragraph after the 1st set of bullet > items: shouldn't this be up to "NUMBER_OF_PATHS" rather than always > "NUMBER_OF_PATHS" paths that are created? Meaning that it's possible > the algorithm will not have sufficient disjoint paths to choose from > in some (probably degenerate) cases? Delete the second comma in the > sentence. > > Page 14, section 8.5.1, 2nd set of bullet items, 2nd bullet item, 1st > sentence: change "A" to "An". > > Page 14, section 8.5.1, 2nd set of bullet items, 2nd bullet item, 2nd > sentence: insert "the" before "Multi-path". > > Page 14, section 8.5.2, 1st sentence: insert "the" before > "Multi-path". > > Page 15, 1st full paragraph, 1st sentence: change the second > occurrence of "Dijkstra" to "Dijkstra's". > > Page 15, 2nd bullet item, 2nd sentence: change "is" to "does". > > Page 15, 1st paragraph after bullet items, 3rd sentence: change > "vetex" to "vertex". > > Page 15, 1st paragraph after figure, 2nd sentence: change "of" to > "for". > > Page 16, 1st sentence: change "Dijkstra" to "Dijkstra's". > > Page 16, 1st paragraph after numbered list: insert "the" before > "Multi-path". > > Page 16, section 8.6, 1st paragraph, last sentence: insert "whether" > before "the set". > > Page 16, section 9, 1st sentence: change "guideline" to "guidelines". > > Page 16, section 9, 2nd sentence: delete the comma after "certain". > > Page 17, "if id greater" instead of "more"? > > Page 19, section 11, 2nd paragraph, 1st sentence: change "Process" to > "Processes". > > Page 19, section 11, 2nd paragraph, 2nd sentence: delete "be". > > Page 19, section 11, 3rd paragraph: append "with" after "As". > > Page 19, section 11, 4th paragraph, 1st sentence: insert "The" before > "MP-OLSRv2". > > Page 19, section 11, 4th paragraph, 2nd sentence: insert "the" before > "source". > > Page 20, 1st paragraph, 4th sentence: should "ancient" be "the > oldest"? > > Page 20, 1st paragraph, 5th sentence: delete comma after "that". > Insert "a" before "large". Maybe change "initiates" to "sends". > Delete the comma after "which". > > Page 24, 1st paragraph after Figure 2, 1st sentence: insert "the" > before "name". Change "name" to "names". > > Page 24, 1st paragraph after Figure 2, 2nd sentence: change > "parenthesis" to "parentheses". > > Page 24, 3rd paragraph after Figure 2, 3rd sentence: while I > understand "punishment", that term hasn't been used previously and > might be confusing. A variant occurs elsewhere in the document. > Consider explaining what you mean by punishment. > > Page 24, 2nd paragraph after Figure 3, 1st sentence: change "path" to > "paths". Append "in order" after "paths". > > Page 24, 3rd paragraph after Figure 3, 2nd sentence: change > "undesired" to "undesirable". > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue May 9 19:49:13 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E54E6128B8D; Tue, 9 May 2017 19:49:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-manet-olsrv2-multipath@ietf.org, aretana@cisco.com, Stan Ratliff , manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 19:49:05 -0700 Archived-At: Subject: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 02:49:06 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-manet-olsrv2-multipath-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I find it really strange that this document uses an experimental Routing header type codepoint (254) but requires the processing to be same as the RPL Routing header (Type 3). Is there a reason things are done this way instead of just using the Type 3 header as is? From nobody Wed May 10 02:29:48 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C855E1252BA; Wed, 10 May 2017 02:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSa-A2peWABC; Wed, 10 May 2017 02:29:45 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377191200C1; Wed, 10 May 2017 02:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494408581; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=1007; bh=zpmZFOTs/aG75hqfLdtMYd8bkkyyUhC3auDkqGQxO1o=; b=quVucy/tlQTsjG7429zxzafCmKD/fnM6LmumtuZV6SFjdTLfqaLJKCT8WowDxbTz VnhR9Ldf8mRTPcdfutMzMoGuSXzLinD1ZyJvKHmC+pOUZ3fTXsWTP2ZbXbleg0mZVjd DihW7H1gOuz1UFbMcDNNE/EBco8lMOdN+dkSwx0w= Received: from [129.104.72.106] (129.104.72.106 [129.104.72.106]) by mx.zohomail.com with SMTPS id 1494408581302942.0830710335102; Wed, 10 May 2017 02:29:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jiazi Yi In-Reply-To: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 11:29:43 +0200 Cc: The IESG , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 09:29:47 -0000 Dear Suresh,=20 Thanks very much for the comments.=20 Alvaro raised the same issue before =E2=80=94 we will use the type 3 = header in the next revision.=20 best Jiazi > On 10 May 2017, at 04:49, Suresh Krishnan = wrote: >=20 > Suresh Krishnan has entered the following ballot position for > draft-ietf-manet-olsrv2-multipath-12: No Objection >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I find it really strange that this document uses an experimental = Routing > header type codepoint (254) but requires the processing to be same as = the > RPL Routing header (Type 3). Is there a reason things are done this = way > instead of just using the Type 3 header as is? >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 10 02:34:00 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142951252BA; Wed, 10 May 2017 02:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5z0nkf5o-3X; Wed, 10 May 2017 02:33:56 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC301243FE; Wed, 10 May 2017 02:33:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,318,1491260400"; d="scan'208";a="181844680" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 10 May 2017 10:33:19 +0100 X-IronPort-AV: E=Sophos;i="5.38,318,1491260400"; d="scan'208";a="170669235" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 10 May 2017 10:33:01 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.172]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 10 May 2017 10:33:00 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi Yi CC: "ietf@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-olsrv2-multipath@ietf.org" , "manet-chairs@ietf.org" Thread-Topic: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC Thread-Index: AQHSuiCA8lo3GCHD2k6nFUb/R8wgmaHr37cAgADIFACAAL4IgA== Date: Wed, 10 May 2017 09:33:00 +0000 Message-ID: References: <149272508088.22258.8263343290438640855.idtracker@ietfa.amsl.com> <9096512E-3473-473A-B6F1-37CBDD82A0F4@jiaziyi.com> In-Reply-To: <9096512E-3473-473A-B6F1-37CBDD82A0F4@jiaziyi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 09:33:59 -0000 QWRkaXRpb25hbCBjb21tZW50cyA+Pj4gYmVsb3cuIFdoYXQgSSdtIHByb3Bvc2luZyAoc3BlbGxl ZCBvdXQgYSBiaXQgbW9yZSkgaXMgYWxsIHdpbiwgYW5kIHJlbW92ZXMgcHJvYmxlbXMgd2l0aCB0 aGUgY3VycmVudCBkZXNpZ24uIEkgdGhpbmsgdGhpcyBpcyBhIG11c3QgZG8uDQoNCi0tIA0KQ2hy aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K VDogwqArNDQgMzMwMCA0Njc1MDAgwqB8IMKgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5v bG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cu YmFlc3lzdGVtcy5jb20vYWkNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0 ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJl ZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZ UA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKaWF6aSBZaSBbbWFpbHRv OmlldGZAamlheml5aS5jb21dIA0KU2VudDogMDkgTWF5IDIwMTcgMjM6NDkNClRvOiBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IGlldGZAaWV0Zi5vcmc7IElFVEYtQW5ub3VuY2U7IG1h bmV0QGlldGYub3JnOyBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGhAaWV0Zi5vcmc7 IG1hbmV0LWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gTGFzdCBDYWxsOiA8 ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEyLnR4dD4gKE11bHRpLXBhdGggRXh0 ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJz aW9uIDIgKE9MU1J2MikpIHRvIEV4cGVyaW1lbnRhbCBSRkMNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdp bmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVy bmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hl dGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMg b3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24g SVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWls IG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KSGkgQ2hyaXMsIA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSBjb21tZW50 cyEgUGxlYXNlIGNoZWNrIG91ciByZXBseSBpbmxpbmU6IA0KDQo+IE9uIDkgTWF5IDIwMTcsIGF0 IDEyOjEzLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20+IHdyb3RlOg0KPiANCj4gQSBmZXcgY29tbWVudHMgb24gdGhpcyBkcmFmdC4NCj4g DQo+IElQdjYgc3BlY2lmaWVzIGNvbXBsZXRlIHNvdXJjZSByb3V0aW5nLiBCdXQgdGhpcyBzcGVj aWZpY2F0aW9uIGNhbiBvbmx5IGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoaW4gdGhlIE1BTkVU LiBTbyBmb3IgYSBwYWNrZXQgZnJvbSBzb21ld2hlcmUgaW4gdGhlIE1BTkVUIHRvIHNvbWV3aGVy ZSB3ZWxsIG91dHNpZGUgdGhlIE1BTkVULCB0aGUgcGFja2V0IG11c3QgYmUgc291cmNlIHJvdXRl ZCB0byB0aGUgZ2F0ZXdheSBiZXR3ZWVuIE1BTkVUIGFuZCByZXN0IG9mIEludGVybmV0LCBhbmQg bm90IHNvdXJjZSByb3V0ZWQgYWZ0ZXIgdGhhdC4gVGhpcyBJIHRoaW5rIHNob3VsZCBiZSBleHBs aWNpdGx5IG1lbnRpb25lZC4gV2hldGhlciB0aGF0IGlzIGNvbnNpZGVyZWQgY29tcGxpYW50IHdp dGggSVB2NiBJIGxlYXZlIHRvIG90aGVycy4NCg0KR29vZCBwb2ludC4gV2UgYWRkZWQgc29tZSB0 ZXh0IGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA4LjQiIERhdGFncmFtIFByb2Nlc3NpbmcgYXQgdGhl IE1QLU9MU1J2MiBPcmlnaW5hdG9yIg0KDQo+IA0KPiA3LjEgU1JfYWRkciB3b3VsZCBiZXR0ZXIg c2F5ICJvcmlnaW5hdG9yIiBhZGRyZXNzIHJhdGhlciB0aGFuIA0KPiAibmV0d29yayIgYWRkcmVz cy4gKFRoYXQgbWFrZXMgaXQgYW4gYWRkcmVzcyB3aXRob3V0IGEgbmV0bWFzaywgc2VlIA0KPiBS RkMgNzE4MS4pDQoNCmZpeGVkLiANCg0KPiANCj4gOC4xIFRoaXMgaXMgc3VnZ2VzdGluZyBjcmVh dGluZyBUQyBtZXNzYWdlcyB0aGF0IGhhdmUgb24gbmVpZ2hib3VyIGFkZHJlc3NlcyBidXQgaGF2 ZSBvbmx5IGEgU09VUkNFX1JPVVRFIFRMVi4gVGhpcyBpcyBub3QgdGhlIGRlc2lnbiBJIHdvdWxk IGhhdmUgc3VnZ2VzdGVkIGFzIGNvbnNpc3RlbnQgd2l0aCBob3cgSSB3b3VsZCBleHBlY3QgYW4g ZXh0ZW5zaW9uIHRvIE9MU1J2MiB0byBkbyB0aGluZ3MuIFdlIG5lZWQgdG8gY29uc2lkZXIgdHdv IGtpbmRzIG9mIHJvdXRlcnM6IHRob3NlIHNlbmRpbmcgVEMgbWVzc2FnZXMgYW55d2F5LCB0aG9z ZSB0aGF0IChvdGhlciB0aGFuIHRoaXMgZXh0ZW5zaW9uKSBkbyBub3QuIEluIHRoZSBmb3JtZXIg Y2FzZSB5b3UgY291bGQganVzdCBhZGQgdGhlIFNPVVJDRV9ST1VURSBUTFYgdG8gdGhvc2UgVEMg bWVzc2FnZXMgaXQgc2VuZHMuIFRoZW4gdGhhdCBpbmZvcm1hdGlvbiBpcyBtYWludGFpbmVkIHVw IHRvIGRhdGUuIFJvdXRlcnMgdGhhdCBkb24ndCB1c3VhbGx5IHNlbmQgVEMgbWVzc2FnZXMgY291 bGQgc2VuZCBUQyBtZXNzYWdlcyB3aXRoIGp1c3QgdGhhdCBUTFYuIEJ1dCB0aGVuIHRoZXJlJ3Mg YW4gaXNzdWUgb3ZlciB2YWxpZGl0eSB0aW1lLiBBIHBhcmFtZXRlciBTUl9IT0xEX1RJTUVfTVVM VElQTElFUiBpcyBpbnRyb2R1Y2VkLiBUaGVyZSdzIG5vIG5lZWQgZm9yIHRoYXQgLSB5b3UgY2Fu IHNpbXBseSBpbmNvcnBvcmF0ZSB0aGF0IGludG8gdGhlIHZhbGlkaXR5IHRpbWUgcmVjb3JkZWQg aW4gdGhlIG1lc3NhZ2UuIFRoYXQgYXZvaWRzIGEgbmVlZCB0byBoYW5kbGUgdGhlIHR3byBjYXNl cyBvZiByb3V0ZXJzIGRpZmZlcmVudGx5LiBUaGVyZSBpcyB0aGVuIGFuIG9kZGl0eSB0aGF0IHlv dSBnZXQgc29tZSByb3V0ZXJzIHNlbmRpbmcgVEMgbWVzc2FnZXMgd2l0aCBub3JtYWwgdmFsaWRp dHkgdGltZXMgYW5kIGFkZHJlc3NlcywgYW5kIHNvbWUgdGhhdCBjYW4gYmUgc2VudCBsZXNzIGZy ZXF1ZW50bHkgd2l0aCBubyBhZGRyZXNzZXMgYW5kIGxvbmdlciB2YWxpZGl0eSB0aW1lcy4gQnV0 IHRoYXQncyBzdXNwZWN0IC0gbm90ZSB0aGF0IGl0J3Mgbm90IGRvbmUgaW4gT0xTUnYyIGZvciBh dHRhY2hlZCBuZXR3b3JrcyAoYW5vdGhlciByZWFzb24gdG8gc2VuZCBUQyBtZXNzYWdlcyBhbHRo b3VnaCBubyBuZWlnaGJvdXJzIG5lZWQgcmVwb3J0aW5nKS4gVGhhdCdzIGJlY2F1c2UgbG9uZ2Vy IGludGVydmFscyBtYWtlIHJlYWN0aW5nIHRvIG5ldyByb3V0ZXJzIGpvaW5pbmcgKGFuZCBuZXR3 b3JrIHJlYXNzZW1ibHkgYWZ0ZXIgZnJhZ21lbnRhdGlvbikgc2xvdy4NCj4gUmF0aGVyIGEgYmV0 dGVyIGRlc2lnbiB3b3VsZCBzaW1wbHkgYmUgdG8gYWRkIFNPVVJDRV9ST1VURSBUTFYgdG8gbm9y bWFsIFRDIG1lc3NhZ2VzLiBXaGVuIHNlbmRpbmcgVEMgbWVzc2FnZXMgZm9yIGp1c3QgdGhhdCBy ZWFzb24sIHRoYXQgY291bGQgYmUganVzdCB0aGUgdXN1YWwgY2FzZSwgYnV0IHlvdSBjb3VsZCBh bGxvdyBhcyBhbiBvcHRpb24gaW4gdGhpcyBjYXNlIHRvIHNlbmQgbGVzcyBmcmVxdWVudGx5IHdp dGggdmFsaWRpdHkgdGltZSBpbmNyZWFzZWQgYWNjb3JkaW5nbHkuIFdoZW4gbm90IHVzaW5nIHRo YXQgb3B0aW9uLCBvbmNlIGEgcm91dGVyIG5lZWRzIHRvIHNlbmQgYSBUQyBtZXNzYWdlLCBpdCBj b3VsZCB0aGVuIGRlY2lkZSB0byByZXBvcnQgbmVpZ2hib3VycywgaW5jcmVhc2luZyB0aGUgdG9w b2xvZ3kgZGlzdHJpYnV0ZWQgYW5kIGFsbG93aW5nIG1vcmUgcm91dGVzLCB0aGlzIGFsc28gYmVp bmcgYW4gb3B0aW9uLg0KPiANCg0KSUlSQywgd2UgaGFkIGEgbG9uZyBkaXNjdXNzaW9uIG9uIHRo aXMgaXNzdWUgYW5kIHByb2R1Y2VkIHRoZSBjdXJyZW50IHRleHQuIA0KVGhlIHB1cnBvc2UgaXMg dG8gaWRlbnRpZnkgdGhlIHJvdXRlcnMgdGhhdCBkb27igJl0IHNlbmQgVEMgbWVzc2FnZXMgYnV0 IHN1cHBvcnQgc291cmNlIHJvdXRpbmcuIFRvIGF2b2lkIHVubmVjZXNzYXJ5IFRDIGZsb29kaW5n LCB0aGUgaW50ZXJ2YWwgaXMgbXVjaCBsb25nZXIgdGhhbiB0aGUgbm9ybWFsIFRDIGludGVydmFs LiANClRoZSBub3JtYWwgVEMgbWVzc2FnZXMgKGdlbmVyYXRlZCBiYXNlZCBvbiBSRkM3MTgxKSBh bHdheXMgaGF2ZSBhIFNPVVJDRV9ST1VURSBUTFYuIEJ1dCBpZiB3ZSB1c2UgdGhlIHNhbWUgdmFs aWRpdHkgdGltZSBmb3IgYm90aCBSRkM3MTgxIG5vcm1hbCBUQyBwcm9jZXNzaW5nIGFuZCBNUC1P TFNSdjIgU1JfUk9VVEUgVExWIHByb2Nlc3NpbmcsIHRoZSB2YWxpZCB0aW1lIGluIHRoZSBTUi1P TFNSdjIgUm91dGVyIFNldCB3b3VsZCBiZSBtdWNoIHNob3J0ZXIgdGhhbiBleHBlY3RlZC4gQSBw b3NzaWJsZSBjYXNlIGlzIHRoYXQsIHRoZSByb3V0ZXIgc3RvcHMgc2VuZGluZyBub3JtYWwgVEMg bWVzc2FnZXMsIHRoZSBjb3JyZXNwb25kaW5nIGVudHJ5IGluIHRoZSBTUi1PTFNSdjIgUm91dGVy IHNldCB3aWxsIHNvb24gZXhwaXJlLiANClRoZXJlZm9yZSwgSSB0aGluayBpdOKAmXMgcmVhc29u YWJsZSB0byBtYWtlIHVzZSBvZiB0aGUgU1JfSE9MRF9USU1FX01VTFRJUExJRVIgdG8gZGlzdGlu Z3Vpc2ggdGhlIHZhbGlkIHRpbWUgb2Ygbm9ybWFsIFRDIG1lc3NhZ2UgaW5mb3JtYXRpb24gYW5k IFNSX1JPVVRFIGluZm9ybWF0aW9uLiANCg0KPj4+IEkgZG9uJ3QgYWdyZWUsIGFuZCBJIHRoaW5r IHdoYXQgeW91IGFyZSBzdWdnZXN0aW5nIGludHJvZHVjZXMgYSBwcm9ibGVtIGFuZCB1bm5lY2Vz c2FyeSBvdmVyaGVhZC4NCg0KPj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgZXZlcnl3aGVyZSBpbiBP TFNSdjIgd2UgYXJlIGNhcmVmdWwgdG8gZW5zdXJlIHRoYXQgcGFyYW1ldGVycyBjYW4gYmUgaW5k ZXBlbmRlbnRseSBzZXQsIGFuZCB0aGF0IHJvdXRlcnMgZG9uJ3QgbmVlZCB0byBjb29yZGluYXRl IHRvIGludGVyb3BlcmF0ZS4gKFRoZXkgbWF5IGRvIGJldHRlciBpZiB0aGV5IGRvLCBidXQgdGhh dCdzIGEgcmVmaW5lbWVudC4pIEhlcmUgeW91IGFyZSB1c2luZyBhbiBTUl9IT0xEX1RJTUVfTVVM VElQTElFUiB0aGF0IHRoZSByZWNlaXZlciBoYXMgdG8ga25vdyBpcyB3aGF0IHRoZSBzZW5kZXIg aW50ZW5kcy4gQW5kIGl0J3MgdW5uZWNlc3NhcnkuIElmIGFsbCB0aGF0J3MgaW4gdGhlIFRDIG1l c3NhZ2UgaXMgdGhlIFNPVVJDRV9ST1VURSBUTFYsIHlvdSBjYW4ganVzdCBnaXZlIHRoYXQgYSBs b25nZXIgdmFsaWRpdHkgdGltZSwgYmVjYXVzZSB0aGUgb25seSB0aGluZyB0aGF0IHZhbGlkaXR5 IHRpbWUgd2lsbCBpbXBhY3Qgb24gaXMgdGhlIHNvdXJjZSByb3V0aW5nIHN0YXR1cy4gSWYgdGhl IHJvdXRlciBpcyBhbHNvIHNlbmRpbmcgbm9ybWFsIFRDIG1lc3NhZ2VzIGFuZCB5b3Ugc2VuZCBz ZXBhcmF0ZSBTT1VSQ0VfUk9VVEUgVExWIFRDIG1lc3NhZ2VzIHRoZW4gdGhhdCB3b3VsZCBzdGls bCBiZSBzby4gQnV0IHRoYXQncyBpbmVmZmljaWVudCwgYmVjYXVzZSBpZiB0aGUgcm91dGVyIGlz IGFscmVhZHkgc2VuZGluZyBUQyBtZXNzYWdlcywgd2h5IHNlbmQgc2VwYXJhdGUgb25lcyB3aXRo IGFkZGVkIG92ZXJoZWFkLCB3aGVuIHlvdSBjYW4gcHV0IHRoZSBTT1VSQ0VfUk9VVEUgVExWIGlu IHRoZSBzYW1lIFRDIG1lc3NhZ2U/IFRoYXQgd291bGQgdGhlbiAod2l0aG91dCBTUl9IT0xEX1RJ TUVfTVVMVElQTElFUiwgYnV0IHRoYXQncyBhIGdvb2QgdGhpbmcgYmVjYXVzZSBTUl9IT0xEX1RJ TUVfTVVMVElQTElFUiBpcyBub3QgZ29vZCkgZ2l2ZSBhIHNob3J0ZXIgdmFsaWRpdHkgdGltZSB0 byB0aGUgU09VUkNFX1JPVVRFIFRMViwgYnV0IHRoYXQncyBmaW5lLCBiZWNhdXNlIHRoYXQgcm91 dGVyIHdpbGwgYmUgc2VuZGluZyBtb3JlIFRDIG1lc3NhZ2VzIHdpdGhpbiB0aGF0IHRpbWVzY2Fs ZSBhbnl3YXkuIEZ1cnRoZXJtb3JlLCB0aGlzIGFsc28gYWxsb3dzIHRoZSByb3V0ZXIgdGhhdCdz IHNlbmRpbmcgVEMgbWVzc2FnZXMgbW9yZSBmcmVxdWVudGx5IHRvIHByb3ZpZGUgaXRzIGluZm9y bWF0aW9uIG1vcmUgcmVzcG9uc2l2ZWx5IGluIHRoZSBjYXNlcyBvZiBub2RlcyBqb2luaW5nIGFu ZCBuZXR3b3JrcyByZWFzc2VtYmxpbmcuDQoNCj4+PiBUaGF0IGdpdmVzIHR3byBiZWhhdmlvdXJz OiByb3V0ZXJzIHNlbmRpbmcgVEMgbWVzc2FnZXMgYW55d2F5LCBqdXN0IGFkZCBhIFNPVVJDRV9S T1VURSBUTFYsIGFuZCByb3V0ZXJzIG5vdCBzZW5kaW5nIFRDIG1lc3NhZ2VzIG90aGVyd2lzZSwg anVzdCBpbmNsdWRlIGEgU09VUkNFX1JPVVRFIFRMViBhbmQgc2V0IHRoZSB2YWxpZGl0eSB0aW1l IGFjY29yZGluZyB0byB3aGF0IHNjaGVkdWxlIHRoYXQgcm91dGVyIGNob29zZXMgdG8gdXNlIC0g d2hpY2ggY2FuIGJlIGF0IHRoZSBzYW1lIHJhdGUgYXMgdGhlIG90aGVyIHJvdXRlcnMsIG9yIGF0 IGEgc2xvd2VyIHJvdXRlLCBvciAoYSBuZXcgY2FwYWJpbGl0eSB5b3UgZG9uJ3QgaGF2ZSkgc2xv d2x5LCBleGNlcHQgaWYgeW91IGxlYXJuIG9mIHRoZSBleGlzdGVuY2Ugb2YgYSBuZXcgcm91dGVy IGluIHRoZSBuZXR3b3JrIHlvdSBjYW4gc2VuZCBvbmUgb3IgbW9yZSByZXNwb25zaXZlIFNPVVJD RV9ST1VURSBUTFYgb25seSBUTFZzIHRvIGVuYWJsZSB0aGF0IG5ldyByb3V0ZXIgKG9yIHJvdXRl cnMpIHRvIGxlYXJuIG9mIHRoZSBzb3VyY2Ugcm91dGluZyBxdWlja2VyLg0KDQo+Pj4gSXQncyBh bGwgd2luOiBjb21iaW5pbmcgbWVzc2FnZXMsIHNvdXJjZSBzZXQgY29udHJvbCwgYWJpbGl0eSB0 byBkbyBtb3JlIGNsZXZlciB0aGluZ3MgaWYgeW91IHdhbnQgdG8uIChZb3UgY291bGQgcHJvYmFi bHkgIGV2ZW4gc3RpbGwgc2VuZCBzZXBhcmF0ZSBUQyBtZXNzYWdlcyB3aXRoIGEgU09VUkNFX1JP VVRFIFRMViB3aGVuIGFsc28gc2VuZGluZyBub3JtYWwgVEMgbWVzc2FnZXMgaWYgeW91IHJlYWxs eSB3YW50ZWQgdG8sIGFzIGFuIG9wdGlvbiBJIGNhbid0IHNlZSB3YW50aW5nIHRvIHVzZSAtIGFs dGhvdWdoIGl0IG1pZ2h0IGludHJvZHVjZSBhIG1pbm9yIHByb2JsZW0gdGhhdCBJIGhhdmVuJ3Qg d29ya2VkIHRocm91Z2ggdGhlIE9MU1J2MiBzcGVjaWZpY2F0aW9uIHRvIGNoZWNrLCBiZWNhdXNl IGl0J3MgdW5uZWNlc3NhcnkuKQ0KDQo+Pj4gVGhlIHBvaW50IGlzIHRoYXQgd2hhdCBJIHN1Z2dl c3QgY2FuIGdhaW4gZXZlcnl0aGluZyB5b3UgZG8sIGFuZCBhbGxvdyBtb3JlLCBwbHVzIG5vdCBi cmVha2luZyBleHBlY3RlZCBPTFNSdjIgYmVoYXZpb3VyLg0KDQo+IDguMyBzZWNvbmQgYnVsbGV0 LiBZb3Ugc2hvdWxkIGhlcmUgKGFuZCBwb3NzaWJseSBlbHNld2hlcmUpIGV4Y2x1ZGUgcm91dGVy cyB3aXRoIHJvdXRpbmcgd2lsbGluZ25lc3MgemVyby4NCg0KPiANCj4gOC4zIHRoZXJlIHNlZW1z IHRvIGJlIGFuIGluY29uc2lzdGVuY3kuIFdoZW4gb3BlcmF0aW5nIHByb2FjdGl2ZWx5IGFuZCBu byBtdWx0aXBsZSByb3V0ZXMsIGRyb3AgdGhlIHBhY2tldCwgYnV0IHJlYWN0aXZlbHkgdXNlIHN0 YW5kYXJkIHJvdXRpbmcuIFRoZSBsYXR0ZXIgc2VlbXMgbW9yZSBhcHByb3ByaWF0ZSBpbiB0aGUg Zm9ybWVyIGNhc2UgYWxzby4NCj4gDQo+IDkgQ1VUT0ZGX1JBVElPLiBJbnNpc3RzIG9mIHN0cmlj dGx5LCBidXQgYXMgZGVmaW5lZCBlYXJsaWVyLCBtYXkgYmUgPj0gMWAuDQoNCkFsbCBmaXhlZC4g DQoNClRoYW5rcyBhZ2FpbiBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzIQ0KDQpiZXN0DQoNCkpp YXppDQoNCj4gDQo+IC0tDQo+IENocmlzdG9waGVyIERlYXJsb3ZlDQo+IFNlbmlvciBQcmluY2lw YWwgRW5naW5lZXINCj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9y aWVzIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IF9fX18NCj4gDQo+IFQ6ICArNDQgMzMwMCA0Njc1MDAg IHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tDQo+IA0KPiBCQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCj4gd3d3LmJhZXN5c3RlbXMuY29tL2Fp DQo+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQgUmVnaXN0ZXJlZCBp biBFbmdsYW5kICYgV2FsZXMgDQo+IE5vOiAwMTMzNzQ1MSBSZWdpc3RlcmVkIE9mZmljZTogU3Vy cmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgDQo+IFN1cnJleSwgR1UyIDdZUA0KPiANCj4g DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hbmV0IFttYWlsdG86bWFu ZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJRVNHDQo+IFNlbnQ6IDIwIEFw cmlsIDIwMTcgMjI6NTENCj4gVG86IElFVEYtQW5ub3VuY2UNCj4gQ2M6IG1hbmV0QGlldGYub3Jn OyBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGhAaWV0Zi5vcmc7IA0KPiBtYW5ldC1j aGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW21hbmV0XSBMYXN0IENhbGw6IDxkcmFmdC1pZXRm LW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTIudHh0PiANCj4gKE11bHRpLXBhdGggRXh0ZW5zaW9u IGZvciB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCANCj4gdmVyc2lv biAyIChPTFNSdjIpKSB0byBFeHBlcmltZW50YWwgUkZDDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tISBXQVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3Jp Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCj4gQ29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Lg0KPiBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxp bmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3Vz IGVtYWlsIG1lc3NhZ2VzLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gKioqIFdBUk5JTkcgKioqDQo+IEVYVEVSTkFMIEVN QUlMIC0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0 aW9uLg0KPiANCj4gDQo+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUg TW9iaWxlIEFkLWhvYyBOZXR3b3JrcyBXRw0KPiAobWFuZXQpIHRvIGNvbnNpZGVyIHRoZSBmb2xs b3dpbmcgZG9jdW1lbnQ6DQo+IC0gJ011bHRpLXBhdGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1p emVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbA0KPiAgIHZlcnNpb24gMiAoT0xTUnYyKScN Cj4gIDxkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTIudHh0PiBhcyBFeHBlcmlt ZW50YWwgUkZDDQo+IA0KPiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhl IG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rp b24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZSBpZXRmQGlldGYub3Jn IG1haWxpbmcgbGlzdHMgYnkgMjAxNy0wNS0wNC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5 IGJlIHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNl IHJldGFpbiB0aGUgYmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21h dGVkIHNvcnRpbmcuDQo+IA0KPiBBYnN0cmFjdA0KPiANCj4gDQo+ICAgVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgYSBtdWx0aS1wYXRoIGV4dGVuc2lvbiBmb3IgdGhlIE9wdGltaXplZCBMaW5rDQo+ ICAgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDIgKE9MU1J2MikgdG8gZGlzY292ZXIg bXVsdGlwbGUNCj4gICBkaXNqb2ludCBwYXRocywgc28gYXMgdG8gaW1wcm92ZSByZWxpYWJpbGl0 eSBvZiB0aGUgT0xTUnYyIHByb3RvY29sLg0KPiAgIFRoZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGgg T0xTUnYyIGlzIHJldGFpbmVkLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIGZpbGUgY2FuIGJlIG9i dGFpbmVkIHZpYQ0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgvDQo+IA0KPiBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRy YWNrZWQgdmlhDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bWFuZXQtb2xzcnYyLW11bHRpcGF0aC9iYWwNCj4gbG90Lw0KPiANCj4gDQo+IE5vIElQUiBkZWNs YXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC4NCj4gDQo+ IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+IA0KPiANCj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cj4gVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhl IGludGVuZGVkIA0KPiByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCANCj4gcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJv bSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuDQo+IFlvdSBzaG91bGQgbm90IGNv cHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IgDQo+IGRpc3Ry aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQo+ICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ IA0KDQoNCg== From nobody Wed May 10 05:41:11 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D89129423; Wed, 10 May 2017 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWAdAhhi0b8G; Wed, 10 May 2017 05:41:06 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4278126DFB; Wed, 10 May 2017 05:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494420062; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=68805; bh=pFsjUVy51QkluRZLisUECPt+Vcpd01JEttGel8Unjhw=; b=flHvQY3EmpsHn/f4T3SxDFBBAo2iWFrpk+ohCkcEQkm3p6KQprbk5yHeMMdQ9KyR D1KgNzR4dMzAr89SQxjvvzSq3ks7eyjnHWFwUU767LqTXtkiwgBNZDboc3jsJVm3P3m LBcyQUxw/OqVB7SRlm+MQaV/0DU4Yh5P0mlh9PzA= Received: from [129.104.72.106] (129.104.72.106 [129.104.72.106]) by mx.zohomail.com with SMTPS id 1494420062336240.46827593410194; Wed, 10 May 2017 05:41:02 -0700 (PDT) From: Jiazi Yi Message-Id: <03E51133-21B1-45EE-8888-52D251667891@jiaziyi.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4BD8F23A-41E1-49F4-B7A6-D52C72BFF50B" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 14:40:59 +0200 In-Reply-To: Cc: "ietf@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-olsrv2-multipath@ietf.org" , "manet-chairs@ietf.org" To: "Dearlove, Christopher (UK)" References: <149272508088.22258.8263343290438640855.idtracker@ietfa.amsl.com> <9096512E-3473-473A-B6F1-37CBDD82A0F4@jiaziyi.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 12:41:09 -0000 --Apple-Mail=_4BD8F23A-41E1-49F4-B7A6-D52C72BFF50B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Chris,=20 OK, it makes sense. So the policy will be: - the SOURCE_ROUTE TLV won=E2=80=99t have any value - Every TC message originated by the source-route supported = routers will have a SOURCE_ROUTE TLV - The TC message not containing any neighbour address will have = a longer validity time compared to OLSRv2 normal TC messages.=20 best Jiazi > On 10 May 2017, at 11:33, Dearlove, Christopher (UK) = wrote: >=20 > Additional comments >>> below. What I'm proposing (spelled out a bit = more) is all win, and removes problems with the current design. I think = this is a must do. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > = __________________________________________________________________________= >=20 > T: +44 3300 467500 | E: chris.dearlove@baesystems.com = >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 >=20 > -----Original Message----- > From: Jiazi Yi [mailto:ietf@jiaziyi.com ]=20 > Sent: 09 May 2017 23:49 > To: Dearlove, Christopher (UK) > Cc: ietf@ietf.org ; IETF-Announce; = manet@ietf.org ; = draft-ietf-manet-olsrv2-multipath@ietf.org = ; = manet-chairs@ietf.org > Subject: Re: [manet] Last Call: = (Multi-path Extension for the = Optimized Link State Routing Protocol version 2 (OLSRv2)) to = Experimental RFC >=20 > ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi Chris,=20 >=20 > Thanks a lot for the comments! Please check our reply inline:=20 >=20 >> On 9 May 2017, at 12:13, Dearlove, Christopher (UK) = wrote: >>=20 >> A few comments on this draft. >>=20 >> IPv6 specifies complete source routing. But this specification can = only consider what happens within the MANET. So for a packet from = somewhere in the MANET to somewhere well outside the MANET, the packet = must be source routed to the gateway between MANET and rest of Internet, = and not source routed after that. This I think should be explicitly = mentioned. Whether that is considered compliant with IPv6 I leave to = others. >=20 > Good point. We added some text at the end of section 8.4" Datagram = Processing at the MP-OLSRv2 Originator" >=20 >>=20 >> 7.1 SR_addr would better say "originator" address rather than=20 >> "network" address. (That makes it an address without a netmask, see=20= >> RFC 7181.) >=20 > fixed.=20 >=20 >>=20 >> 8.1 This is suggesting creating TC messages that have on neighbour = addresses but have only a SOURCE_ROUTE TLV. This is not the design I = would have suggested as consistent with how I would expect an extension = to OLSRv2 to do things. We need to consider two kinds of routers: those = sending TC messages anyway, those that (other than this extension) do = not. In the former case you could just add the SOURCE_ROUTE TLV to those = TC messages it sends. Then that information is maintained up to date. = Routers that don't usually send TC messages could send TC messages with = just that TLV. But then there's an issue over validity time. A parameter = SR_HOLD_TIME_MULTIPLIER is introduced. There's no need for that - you = can simply incorporate that into the validity time recorded in the = message. That avoids a need to handle the two cases of routers = differently. There is then an oddity that you get some routers sending = TC messages with normal validity times and addresses, and some that can = be sent less frequently with no addresses and longer validity times. But = that's suspect - note that it's not done in OLSRv2 for attached networks = (another reason to send TC messages although no neighbours need = reporting). That's because longer intervals make reacting to new routers = joining (and network reassembly after fragmentation) slow. >> Rather a better design would simply be to add SOURCE_ROUTE TLV to = normal TC messages. When sending TC messages for just that reason, that = could be just the usual case, but you could allow as an option in this = case to send less frequently with validity time increased accordingly. = When not using that option, once a router needs to send a TC message, it = could then decide to report neighbours, increasing the topology = distributed and allowing more routes, this also being an option. >>=20 >=20 > IIRC, we had a long discussion on this issue and produced the current = text.=20 > The purpose is to identify the routers that don=E2=80=99t send TC = messages but support source routing. To avoid unnecessary TC flooding, = the interval is much longer than the normal TC interval.=20 > The normal TC messages (generated based on RFC7181) always have a = SOURCE_ROUTE TLV. But if we use the same validity time for both RFC7181 = normal TC processing and MP-OLSRv2 SR_ROUTE TLV processing, the valid = time in the SR-OLSRv2 Router Set would be much shorter than expected. A = possible case is that, the router stops sending normal TC messages, the = corresponding entry in the SR-OLSRv2 Router set will soon expire.=20 > Therefore, I think it=E2=80=99s reasonable to make use of the = SR_HOLD_TIME_MULTIPLIER to distinguish the valid time of normal TC = message information and SR_ROUTE information.=20 >=20 >>>> I don't agree, and I think what you are suggesting introduces a = problem and unnecessary overhead. >=20 >>>> The problem is that everywhere in OLSRv2 we are careful to ensure = that parameters can be independently set, and that routers don't need to = coordinate to interoperate. (They may do better if they do, but that's a = refinement.) Here you are using an SR_HOLD_TIME_MULTIPLIER that the = receiver has to know is what the sender intends. And it's unnecessary. = If all that's in the TC message is the SOURCE_ROUTE TLV, you can just = give that a longer validity time, because the only thing that validity = time will impact on is the source routing status. If the router is also = sending normal TC messages and you send separate SOURCE_ROUTE TLV TC = messages then that would still be so. But that's inefficient, because if = the router is already sending TC messages, why send separate ones with = added overhead, when you can put the SOURCE_ROUTE TLV in the same TC = message? That would then (without SR_HOLD_TIME_MULTIPLIER, but that's a = good thing because SR_HOLD_TIME_MULTIPLIER is not good) give a shorter = validity time to the SOURCE_ROUTE TLV, but that's fine, because that = router will be sending more TC messages within that timescale anyway. = Furthermore, this also allows the router that's sending TC messages more = frequently to provide its information more responsively in the cases of = nodes joining and networks reassembling. >=20 >>>> That gives two behaviours: routers sending TC messages anyway, just = add a SOURCE_ROUTE TLV, and routers not sending TC messages otherwise, = just include a SOURCE_ROUTE TLV and set the validity time according to = what schedule that router chooses to use - which can be at the same rate = as the other routers, or at a slower route, or (a new capability you = don't have) slowly, except if you learn of the existence of a new router = in the network you can send one or more responsive SOURCE_ROUTE TLV only = TLVs to enable that new router (or routers) to learn of the source = routing quicker. >=20 >>>> It's all win: combining messages, source set control, ability to do = more clever things if you want to. (You could probably even still send = separate TC messages with a SOURCE_ROUTE TLV when also sending normal TC = messages if you really wanted to, as an option I can't see wanting to = use - although it might introduce a minor problem that I haven't worked = through the OLSRv2 specification to check, because it's unnecessary.) >=20 >>>> The point is that what I suggest can gain everything you do, and = allow more, plus not breaking expected OLSRv2 behaviour. >=20 >> 8.3 second bullet. You should here (and possibly elsewhere) exclude = routers with routing willingness zero. >=20 >>=20 >> 8.3 there seems to be an inconsistency. When operating proactively = and no multiple routes, drop the packet, but reactively use standard = routing. The latter seems more appropriate in the former case also. >>=20 >> 9 CUTOFF_RATIO. Insists of strictly, but as defined earlier, may be = >=3D 1`. >=20 > All fixed.=20 >=20 > Thanks again for the valuable comments! >=20 > best >=20 > Jiazi >=20 >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories=20 >> = ______________________________________________________________________ >> ____ >>=20 >> T: +44 3300 467500 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> BAE Systems Applied Intelligence Limited Registered in England & = Wales=20 >> No: 01337451 Registered Office: Surrey Research Park, Guildford,=20 >> Surrey, GU2 7YP >>=20 >>=20 >> -----Original Message----- >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of The IESG >> Sent: 20 April 2017 22:51 >> To: IETF-Announce >> Cc: manet@ietf.org; draft-ietf-manet-olsrv2-multipath@ietf.org;=20 >> manet-chairs@ietf.org >> Subject: [manet] Last Call: = =20 >> (Multi-path Extension for the Optimized Link State Routing Protocol=20= >> version 2 (OLSRv2)) to Experimental RFC >>=20 >> ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external = partner or from the internet. >> Consider carefully whether you should click on any links, open any = attachments or reply. >> Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> *** WARNING *** >> EXTERNAL EMAIL -- This message originates from outside our = organization. >>=20 >>=20 >> The IESG has received a request from the Mobile Ad-hoc Networks WG >> (manet) to consider the following document: >> - 'Multi-path Extension for the Optimized Link State Routing Protocol >> version 2 (OLSRv2)' >> as Experimental RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits = final comments on this action. Please send substantive comments to the = ietf@ietf.org mailing lists by 2017-05-04. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the = beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >>=20 >> This document specifies a multi-path extension for the Optimized = Link >> State Routing Protocol version 2 (OLSRv2) to discover multiple >> disjoint paths, so as to improve reliability of the OLSRv2 protocol. >> The interoperability with OLSRv2 is retained. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ >>=20 >> IESG discussion can be tracked via >> = https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/bal >> lot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> This email and any attachments are confidential to the intended=20 >> recipient and may also be privileged. If you are not the intended=20 >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or=20 >> distribute its contents to any other person. >> ******************************************************************** --Apple-Mail=_4BD8F23A-41E1-49F4-B7A6-D52C72BFF50B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Chris, 

OK, it makes sense. So the policy will = be:

- the = SOURCE_ROUTE TLV won=E2=80=99t have any value
- Every = TC message originated by the source-route supported routers will have a = SOURCE_ROUTE TLV
- The TC message not containing = any neighbour address will have a longer validity time compared to = OLSRv2 normal TC messages. 

best

Jiazi


On 10 May 2017, at 11:33, Dearlove, = Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Additional comments >>> = below. What I'm proposing (spelled out a bit more) is all win, and = removes problems with the current design. I think this is a must = do.

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence = Laboratories
_______________________________________________________________= ___________

T:  +44 3300 467500  | =  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford = Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence = Limited
Registered in England & Wales No: = 01337451
Registered Office: Surrey Research Park, = Guildford, Surrey, GU2 7YP

-----Original Message-----
From: Jiazi Yi [mailto:ietf@jiaziyi.com] 
Sent: 09 May 2017 23:49
To: Dearlove, Christopher (UK)
Cc: ietf@ietf.org; IETF-Announce; manet@ietf.org; draft-ietf-manet-olsrv2-multipath@ietf.org; manet-chairs@ietf.org
Subject: Re: [manet] Last Call: = <draft-ietf-manet-olsrv2-multipath-12.txt> (Multi-path Extension = for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to = Experimental RFC

----------------------! WARNING = ! ---------------------- This message originates from outside our = organisation, either from an external partner or from the = internet.
Consider carefully whether you should = click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT = matters for instructions on reporting suspicious email = messages.
--------------------------------------------------------=

Hi Chris, 
Thanks a lot for the comments! Please check our = reply inline: 
On 9 May 2017, at 12:13, = Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

A few comments on this draft.

IPv6= specifies complete source routing. But this specification can only = consider what happens within the MANET. So for a packet from somewhere = in the MANET to somewhere well outside the MANET, the packet must be = source routed to the gateway between MANET and rest of Internet, and not = source routed after that. This I think should be explicitly mentioned. = Whether that is considered compliant with IPv6 I leave to others.

Good point. We added some text at the end = of section 8.4" Datagram Processing at the MP-OLSRv2 = Originator"


7.1 SR_addr = would better say "originator" address rather than 
"network" = address. (That makes it an address without a netmask, see 
RFC = 7181.)

fixed. 

8.1 This is = suggesting creating TC messages that have on neighbour addresses but = have only a SOURCE_ROUTE TLV. This is not the design I would have = suggested as consistent with how I would expect an extension to OLSRv2 = to do things. We need to consider two kinds of routers: those sending TC = messages anyway, those that (other than this extension) do not. In the = former case you could just add the SOURCE_ROUTE TLV to those TC messages = it sends. Then that information is maintained up to date. Routers that = don't usually send TC messages could send TC messages with just that = TLV. But then there's an issue over validity time. A parameter = SR_HOLD_TIME_MULTIPLIER is introduced. There's no need for that - you = can simply incorporate that into the validity time recorded in the = message. That avoids a need to handle the two cases of routers = differently. There is then an oddity that you get some routers sending = TC messages with normal validity times and addresses, and some that can = be sent less frequently with no addresses and longer validity times. But = that's suspect - note that it's not done in OLSRv2 for attached networks = (another reason to send TC messages although no neighbours need = reporting). That's because longer intervals make reacting to new routers = joining (and network reassembly after fragmentation) slow.
Rather a better design would simply be to add SOURCE_ROUTE = TLV to normal TC messages. When sending TC messages for just that = reason, that could be just the usual case, but you could allow as an = option in this case to send less frequently with validity time increased = accordingly. When not using that option, once a router needs to send a = TC message, it could then decide to report neighbours, increasing the = topology distributed and allowing more routes, this also being an = option.


IIRC, we had a long discussion on this issue and = produced the current text. 
The purpose is to identify the routers that = don=E2=80=99t send TC messages but support source routing. To avoid = unnecessary TC flooding, the interval is much longer than the normal TC = interval. 
The normal TC messages (generated based on = RFC7181) always have a SOURCE_ROUTE TLV. But if we use the same validity = time for both RFC7181 normal TC processing and MP-OLSRv2 SR_ROUTE TLV = processing, the valid time in the SR-OLSRv2 Router Set would be much = shorter than expected. A possible case is that, the router stops sending = normal TC messages, the corresponding entry in the SR-OLSRv2 Router set = will soon expire. 
Therefore, I think it=E2=80=99s reasonable to = make use of the SR_HOLD_TIME_MULTIPLIER to distinguish the valid time of = normal TC message information and SR_ROUTE information. 
I don't agree, and I = think what you are suggesting introduces a problem and unnecessary = overhead.

The problem is that = everywhere in OLSRv2 we are careful to ensure that parameters can be = independently set, and that routers don't need to coordinate to = interoperate. (They may do better if they do, but that's a refinement.) = Here you are using an SR_HOLD_TIME_MULTIPLIER that the receiver has to = know is what the sender intends. And it's unnecessary. If all that's in = the TC message is the SOURCE_ROUTE TLV, you can just give that a longer = validity time, because the only thing that validity time will impact on = is the source routing status. If the router is also sending normal TC = messages and you send separate SOURCE_ROUTE TLV TC messages then that = would still be so. But that's inefficient, because if the router is = already sending TC messages, why send separate ones with added overhead, = when you can put the SOURCE_ROUTE TLV in the same TC message? That would = then (without SR_HOLD_TIME_MULTIPLIER, but that's a good thing because = SR_HOLD_TIME_MULTIPLIER is not good) give a shorter validity time to the = SOURCE_ROUTE TLV, but that's fine, because that router will be sending = more TC messages within that timescale anyway. Furthermore, this also = allows the router that's sending TC messages more frequently to provide = its information more responsively in the cases of nodes joining and = networks reassembling.

That gives two = behaviours: routers sending TC messages anyway, just add a SOURCE_ROUTE = TLV, and routers not sending TC messages otherwise, just include a = SOURCE_ROUTE TLV and set the validity time according to what schedule = that router chooses to use - which can be at the same rate as the other = routers, or at a slower route, or (a new capability you don't have) = slowly, except if you learn of the existence of a new router in the = network you can send one or more responsive SOURCE_ROUTE TLV only TLVs = to enable that new router (or routers) to learn of the source routing = quicker.

It's all win: combining = messages, source set control, ability to do more clever things if you = want to. (You could probably  even still send separate TC messages = with a SOURCE_ROUTE TLV when also sending normal TC messages if you = really wanted to, as an option I can't see wanting to use - although it = might introduce a minor problem that I haven't worked through the OLSRv2 = specification to check, because it's unnecessary.)

The point is that what I = suggest can gain everything you do, and allow more, plus not breaking = expected OLSRv2 behaviour.

8.3 second bullet. You = should here (and possibly elsewhere) exclude routers with routing = willingness zero.


8.3 there = seems to be an inconsistency. When operating proactively and no multiple = routes, drop the packet, but reactively use standard routing. The latter = seems more appropriate in the former case also.

9 CUTOFF_RATIO. Insists of strictly, but as defined earlier, = may be >=3D 1`.

All fixed. 
Thanks again for the valuable = comments!

best
Jiazi


--
Christopher Dearlove
Senior Principal = Engineer
BAE Systems Applied Intelligence = Laboratories 
_______________________________________________________________= _______
____

T:  +44 = 3300 467500  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, = Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied = Intelligence Limited Registered in England & Wales 
No: 01337451 = Registered Office: Surrey Research Park, Guildford, 
Surrey, GU2 = 7YP


-----Original = Message-----
From: manet [mailto:manet-bounces@ietf.org] = On Behalf Of The IESG
Sent: 20 April 2017 22:51
To: IETF-Announce
Cc: manet@ietf.org; = draft-ietf-manet-olsrv2-multipath@ietf.org; 
manet-chairs@ietf.org
Subject: [manet] Last = Call: <draft-ietf-manet-olsrv2-multipath-12.txt> 
(Multi-path = Extension for the Optimized Link State Routing Protocol 
version 2 = (OLSRv2)) to Experimental RFC

----------------------! WARNING ! ---------------------- This = message originates from outside our organisation, either from an = external partner or from the internet.
Consider carefully = whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for = instructions on reporting suspicious email messages.
--------------------------------------------------------

*** WARNING ***
EXTERNAL EMAIL = -- This message originates from outside our organization.


The IESG has received a request = from the Mobile Ad-hoc Networks WG
(manet) to consider the = following document:
- 'Multi-path Extension for the = Optimized Link State Routing Protocol
 version 2 = (OLSRv2)'
<draft-ietf-manet-olsrv2-multipath-12.txt> = as Experimental RFC

The IESG plans to make = a decision in the next few weeks, and solicits final comments on this = action. Please send substantive comments to the ietf@ietf.org mailing = lists by 2017-05-04. Exceptionally, comments may be sent to = iesg@ietf.org instead. In either case, please retain the beginning of = the Subject line to allow automated sorting.

Abstract


 This= document specifies a multi-path extension for the Optimized Link
 State Routing Protocol version 2 (OLSRv2) to discover = multiple
 disjoint paths, so as to improve = reliability of the OLSRv2 protocol.
 The = interoperability with OLSRv2 is retained.



The file can be obtained = via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multip= ath/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multip= ath/bal
lot/


No = IPR declarations have been submitted directly on this I-D.




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


***************************************************************= *****
This email and any attachments are confidential to = the intended 
recipient and may also be privileged. If you are not the = intended 
recipient please delete it from your system and notify the = sender.
You should not copy it or use it for any purpose = nor disclose or 
distribute its contents to any other person.
***************************************************************= *****

= --Apple-Mail=_4BD8F23A-41E1-49F4-B7A6-D52C72BFF50B-- From nobody Wed May 10 05:54:30 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E056F12943A; Wed, 10 May 2017 05:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoRsQiPlSrAu; Wed, 10 May 2017 05:54:17 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B591293E4; Wed, 10 May 2017 05:54:15 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.38,319,1491260400"; d="scan'208,217"; a="62020819" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 10 May 2017 13:54:13 +0100 X-IronPort-AV: E=Sophos;i="5.38,319,1491260400"; d="scan'208,217";a="170716979" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds016.greenlnk.net with ESMTP; 10 May 2017 13:53:55 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.172]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0248.002; Wed, 10 May 2017 13:53:55 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi Yi CC: "ietf@ietf.org" , "manet@ietf.org" , "draft-ietf-manet-olsrv2-multipath@ietf.org" , "manet-chairs@ietf.org" Thread-Topic: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC Thread-Index: AQHSuiCA8lo3GCHD2k6nFUb/R8wgmaHr37cAgADIFACAAL4IgIAAKoKAgAAUKTA= Date: Wed, 10 May 2017 12:53:55 +0000 Message-ID: References: <149272508088.22258.8263343290438640855.idtracker@ietfa.amsl.com> <9096512E-3473-473A-B6F1-37CBDD82A0F4@jiaziyi.com> <03E51133-21B1-45EE-8888-52D251667891@jiaziyi.com> In-Reply-To: <03E51133-21B1-45EE-8888-52D251667891@jiaziyi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE633147CGLKXM0003vGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Last Call: (Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 12:54:21 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE633147CGLKXM0003vGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBwb2ludCAzIHNob3VsZCBiZSDigJxtYXnigJ0gcmF0aGVyIHRoYW4g4oCcd2lsbOKA nSwgYnV0IG90aGVyd2lzZSBnb29kLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlv ciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExh Ym9yYXRvcmllcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAzMzAwIDQ2NzUwMCAgfCAg RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5 IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IEppYXpp IFlpIFttYWlsdG86aWV0ZkBqaWF6aXlpLmNvbV0NClNlbnQ6IDEwIE1heSAyMDE3IDEzOjQxDQpU bzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCkNjOiBpZXRmQGlldGYub3JnOyBtYW5ldEBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoQGlldGYub3JnOyBtYW5l dC1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIExhc3QgQ2FsbDogPGRyYWZ0 LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMi50eHQ+IChNdWx0aS1wYXRoIEV4dGVuc2lv biBmb3IgdGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAy IChPTFNSdjIpKSB0byBFeHBlcmltZW50YWwgUkZDDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlz IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJl ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0 YWNobWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0 aGF0IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVy ZTxodHRwOi8vd3Mtc2l0ZXMuZW50LmJhZXN5c3RlbXMuY29tL3NpdGVzL0hPU0VDU3Rkc0xpYnJh cnkvU3RhbmRhcmRzTGlicmFyeS9FdmVyeW9uZS9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZl ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0 dHA6Ly93cy1zaXRlcy5lbnQuYmFlc3lzdGVtcy5jb20vc2l0ZXMvSE9TRUNTdGRzTGlicmFyeS9T dGFuZGFyZHNMaWJyYXJ5L0V2ZXJ5b25lL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVt YWlscy5wZGY+Lg0KSGkgQ2hyaXMsDQoNCk9LLCBpdCBtYWtlcyBzZW5zZS4gU28gdGhlIHBvbGlj eSB3aWxsIGJlOg0KDQogICAgICAgICAgICAtIHRoZSBTT1VSQ0VfUk9VVEUgVExWIHdvbuKAmXQg aGF2ZSBhbnkgdmFsdWUNCiAgICAgICAgICAgIC0gRXZlcnkgVEMgbWVzc2FnZSBvcmlnaW5hdGVk IGJ5IHRoZSBzb3VyY2Utcm91dGUgc3VwcG9ydGVkIHJvdXRlcnMgd2lsbCBoYXZlIGEgU09VUkNF X1JPVVRFIFRMVg0KICAgICAgICAgICAgLSBUaGUgVEMgbWVzc2FnZSBub3QgY29udGFpbmluZyBh bnkgbmVpZ2hib3VyIGFkZHJlc3Mgd2lsbCBoYXZlIGEgbG9uZ2VyIHZhbGlkaXR5IHRpbWUgY29t cGFyZWQgdG8gT0xTUnYyIG5vcm1hbCBUQyBtZXNzYWdlcy4NCg0KYmVzdA0KDQpKaWF6aQ0KDQoN Ck9uIDEwIE1heSAyMDE3LCBhdCAxMTozMywgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbT4+IHdyb3RlOg0KDQpBZGRpdGlvbmFsIGNvbW1lbnRzID4+PiBiZWxvdy4gV2hhdCBJ J20gcHJvcG9zaW5nIChzcGVsbGVkIG91dCBhIGJpdCBtb3JlKSBpcyBhbGwgd2luLCBhbmQgcmVt b3ZlcyBwcm9ibGVtcyB3aXRoIHRoZSBjdXJyZW50IGRlc2lnbi4gSSB0aGluayB0aGlzIGlzIGEg bXVzdCBkby4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVu Z2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNClQ6ICArNDQgMzMwMCA0Njc1MDAgIHwgIEU6IGNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4N Cg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9n eSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFl c3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdh bGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJr LCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBKaWF6aSBZaSBbbWFpbHRvOmlldGZAamlheml5aS5jb21dDQpTZW50OiAwOSBN YXkgMjAxNyAyMzo0OQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogaWV0ZkBp ZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IElFVEYtQW5ub3VuY2U7IG1hbmV0QGlldGYu b3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz47IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRp cGF0aEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoQGll dGYub3JnPjsgbWFuZXQtY2hhaXJzQGlldGYub3JnPG1haWx0bzptYW5ldC1jaGFpcnNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1hbmV0LW9s c3J2Mi1tdWx0aXBhdGgtMTIudHh0PiAoTXVsdGktcGF0aCBFeHRlbnNpb24gZm9yIHRoZSBPcHRp bWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5nIFByb3RvY29sIHZlcnNpb24gMiAoT0xTUnYyKSkgdG8g RXhwZXJpbWVudGFsIFJGQw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5HICEgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUg b3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciBmcm9t IHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xp Y2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvbGxvdyB0 aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0 cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIaSBD aHJpcywNCg0KVGhhbmtzIGEgbG90IGZvciB0aGUgY29tbWVudHMhIFBsZWFzZSBjaGVjayBvdXIg cmVwbHkgaW5saW5lOg0KDQoNCk9uIDkgTWF5IDIwMTcsIGF0IDEyOjEzLCBEZWFybG92ZSwgQ2hy aXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlz LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoNCkEgZmV3IGNvbW1lbnRzIG9uIHRo aXMgZHJhZnQuDQoNCklQdjYgc3BlY2lmaWVzIGNvbXBsZXRlIHNvdXJjZSByb3V0aW5nLiBCdXQg dGhpcyBzcGVjaWZpY2F0aW9uIGNhbiBvbmx5IGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3aXRoaW4g dGhlIE1BTkVULiBTbyBmb3IgYSBwYWNrZXQgZnJvbSBzb21ld2hlcmUgaW4gdGhlIE1BTkVUIHRv IHNvbWV3aGVyZSB3ZWxsIG91dHNpZGUgdGhlIE1BTkVULCB0aGUgcGFja2V0IG11c3QgYmUgc291 cmNlIHJvdXRlZCB0byB0aGUgZ2F0ZXdheSBiZXR3ZWVuIE1BTkVUIGFuZCByZXN0IG9mIEludGVy bmV0LCBhbmQgbm90IHNvdXJjZSByb3V0ZWQgYWZ0ZXIgdGhhdC4gVGhpcyBJIHRoaW5rIHNob3Vs ZCBiZSBleHBsaWNpdGx5IG1lbnRpb25lZC4gV2hldGhlciB0aGF0IGlzIGNvbnNpZGVyZWQgY29t cGxpYW50IHdpdGggSVB2NiBJIGxlYXZlIHRvIG90aGVycy4NCg0KR29vZCBwb2ludC4gV2UgYWRk ZWQgc29tZSB0ZXh0IGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA4LjQiIERhdGFncmFtIFByb2Nlc3Np bmcgYXQgdGhlIE1QLU9MU1J2MiBPcmlnaW5hdG9yIg0KDQoNCg0KNy4xIFNSX2FkZHIgd291bGQg YmV0dGVyIHNheSAib3JpZ2luYXRvciIgYWRkcmVzcyByYXRoZXIgdGhhbg0KIm5ldHdvcmsiIGFk ZHJlc3MuIChUaGF0IG1ha2VzIGl0IGFuIGFkZHJlc3Mgd2l0aG91dCBhIG5ldG1hc2ssIHNlZQ0K UkZDIDcxODEuKQ0KDQpmaXhlZC4NCg0KDQoNCjguMSBUaGlzIGlzIHN1Z2dlc3RpbmcgY3JlYXRp bmcgVEMgbWVzc2FnZXMgdGhhdCBoYXZlIG9uIG5laWdoYm91ciBhZGRyZXNzZXMgYnV0IGhhdmUg b25seSBhIFNPVVJDRV9ST1VURSBUTFYuIFRoaXMgaXMgbm90IHRoZSBkZXNpZ24gSSB3b3VsZCBo YXZlIHN1Z2dlc3RlZCBhcyBjb25zaXN0ZW50IHdpdGggaG93IEkgd291bGQgZXhwZWN0IGFuIGV4 dGVuc2lvbiB0byBPTFNSdjIgdG8gZG8gdGhpbmdzLiBXZSBuZWVkIHRvIGNvbnNpZGVyIHR3byBr aW5kcyBvZiByb3V0ZXJzOiB0aG9zZSBzZW5kaW5nIFRDIG1lc3NhZ2VzIGFueXdheSwgdGhvc2Ug dGhhdCAob3RoZXIgdGhhbiB0aGlzIGV4dGVuc2lvbikgZG8gbm90LiBJbiB0aGUgZm9ybWVyIGNh c2UgeW91IGNvdWxkIGp1c3QgYWRkIHRoZSBTT1VSQ0VfUk9VVEUgVExWIHRvIHRob3NlIFRDIG1l c3NhZ2VzIGl0IHNlbmRzLiBUaGVuIHRoYXQgaW5mb3JtYXRpb24gaXMgbWFpbnRhaW5lZCB1cCB0 byBkYXRlLiBSb3V0ZXJzIHRoYXQgZG9uJ3QgdXN1YWxseSBzZW5kIFRDIG1lc3NhZ2VzIGNvdWxk IHNlbmQgVEMgbWVzc2FnZXMgd2l0aCBqdXN0IHRoYXQgVExWLiBCdXQgdGhlbiB0aGVyZSdzIGFu IGlzc3VlIG92ZXIgdmFsaWRpdHkgdGltZS4gQSBwYXJhbWV0ZXIgU1JfSE9MRF9USU1FX01VTFRJ UExJRVIgaXMgaW50cm9kdWNlZC4gVGhlcmUncyBubyBuZWVkIGZvciB0aGF0IC0geW91IGNhbiBz aW1wbHkgaW5jb3Jwb3JhdGUgdGhhdCBpbnRvIHRoZSB2YWxpZGl0eSB0aW1lIHJlY29yZGVkIGlu IHRoZSBtZXNzYWdlLiBUaGF0IGF2b2lkcyBhIG5lZWQgdG8gaGFuZGxlIHRoZSB0d28gY2FzZXMg b2Ygcm91dGVycyBkaWZmZXJlbnRseS4gVGhlcmUgaXMgdGhlbiBhbiBvZGRpdHkgdGhhdCB5b3Ug Z2V0IHNvbWUgcm91dGVycyBzZW5kaW5nIFRDIG1lc3NhZ2VzIHdpdGggbm9ybWFsIHZhbGlkaXR5 IHRpbWVzIGFuZCBhZGRyZXNzZXMsIGFuZCBzb21lIHRoYXQgY2FuIGJlIHNlbnQgbGVzcyBmcmVx dWVudGx5IHdpdGggbm8gYWRkcmVzc2VzIGFuZCBsb25nZXIgdmFsaWRpdHkgdGltZXMuIEJ1dCB0 aGF0J3Mgc3VzcGVjdCAtIG5vdGUgdGhhdCBpdCdzIG5vdCBkb25lIGluIE9MU1J2MiBmb3IgYXR0 YWNoZWQgbmV0d29ya3MgKGFub3RoZXIgcmVhc29uIHRvIHNlbmQgVEMgbWVzc2FnZXMgYWx0aG91 Z2ggbm8gbmVpZ2hib3VycyBuZWVkIHJlcG9ydGluZykuIFRoYXQncyBiZWNhdXNlIGxvbmdlciBp bnRlcnZhbHMgbWFrZSByZWFjdGluZyB0byBuZXcgcm91dGVycyBqb2luaW5nIChhbmQgbmV0d29y ayByZWFzc2VtYmx5IGFmdGVyIGZyYWdtZW50YXRpb24pIHNsb3cuDQpSYXRoZXIgYSBiZXR0ZXIg ZGVzaWduIHdvdWxkIHNpbXBseSBiZSB0byBhZGQgU09VUkNFX1JPVVRFIFRMViB0byBub3JtYWwg VEMgbWVzc2FnZXMuIFdoZW4gc2VuZGluZyBUQyBtZXNzYWdlcyBmb3IganVzdCB0aGF0IHJlYXNv biwgdGhhdCBjb3VsZCBiZSBqdXN0IHRoZSB1c3VhbCBjYXNlLCBidXQgeW91IGNvdWxkIGFsbG93 IGFzIGFuIG9wdGlvbiBpbiB0aGlzIGNhc2UgdG8gc2VuZCBsZXNzIGZyZXF1ZW50bHkgd2l0aCB2 YWxpZGl0eSB0aW1lIGluY3JlYXNlZCBhY2NvcmRpbmdseS4gV2hlbiBub3QgdXNpbmcgdGhhdCBv cHRpb24sIG9uY2UgYSByb3V0ZXIgbmVlZHMgdG8gc2VuZCBhIFRDIG1lc3NhZ2UsIGl0IGNvdWxk IHRoZW4gZGVjaWRlIHRvIHJlcG9ydCBuZWlnaGJvdXJzLCBpbmNyZWFzaW5nIHRoZSB0b3BvbG9n eSBkaXN0cmlidXRlZCBhbmQgYWxsb3dpbmcgbW9yZSByb3V0ZXMsIHRoaXMgYWxzbyBiZWluZyBh biBvcHRpb24uDQoNCklJUkMsIHdlIGhhZCBhIGxvbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIGlzc3Vl IGFuZCBwcm9kdWNlZCB0aGUgY3VycmVudCB0ZXh0Lg0KVGhlIHB1cnBvc2UgaXMgdG8gaWRlbnRp ZnkgdGhlIHJvdXRlcnMgdGhhdCBkb27igJl0IHNlbmQgVEMgbWVzc2FnZXMgYnV0IHN1cHBvcnQg c291cmNlIHJvdXRpbmcuIFRvIGF2b2lkIHVubmVjZXNzYXJ5IFRDIGZsb29kaW5nLCB0aGUgaW50 ZXJ2YWwgaXMgbXVjaCBsb25nZXIgdGhhbiB0aGUgbm9ybWFsIFRDIGludGVydmFsLg0KVGhlIG5v cm1hbCBUQyBtZXNzYWdlcyAoZ2VuZXJhdGVkIGJhc2VkIG9uIFJGQzcxODEpIGFsd2F5cyBoYXZl IGEgU09VUkNFX1JPVVRFIFRMVi4gQnV0IGlmIHdlIHVzZSB0aGUgc2FtZSB2YWxpZGl0eSB0aW1l IGZvciBib3RoIFJGQzcxODEgbm9ybWFsIFRDIHByb2Nlc3NpbmcgYW5kIE1QLU9MU1J2MiBTUl9S T1VURSBUTFYgcHJvY2Vzc2luZywgdGhlIHZhbGlkIHRpbWUgaW4gdGhlIFNSLU9MU1J2MiBSb3V0 ZXIgU2V0IHdvdWxkIGJlIG11Y2ggc2hvcnRlciB0aGFuIGV4cGVjdGVkLiBBIHBvc3NpYmxlIGNh c2UgaXMgdGhhdCwgdGhlIHJvdXRlciBzdG9wcyBzZW5kaW5nIG5vcm1hbCBUQyBtZXNzYWdlcywg dGhlIGNvcnJlc3BvbmRpbmcgZW50cnkgaW4gdGhlIFNSLU9MU1J2MiBSb3V0ZXIgc2V0IHdpbGwg c29vbiBleHBpcmUuDQpUaGVyZWZvcmUsIEkgdGhpbmsgaXTigJlzIHJlYXNvbmFibGUgdG8gbWFr ZSB1c2Ugb2YgdGhlIFNSX0hPTERfVElNRV9NVUxUSVBMSUVSIHRvIGRpc3Rpbmd1aXNoIHRoZSB2 YWxpZCB0aW1lIG9mIG5vcm1hbCBUQyBtZXNzYWdlIGluZm9ybWF0aW9uIGFuZCBTUl9ST1VURSBp bmZvcm1hdGlvbi4NCg0KDQpJIGRvbid0IGFncmVlLCBhbmQgSSB0aGluayB3aGF0IHlvdSBhcmUg c3VnZ2VzdGluZyBpbnRyb2R1Y2VzIGEgcHJvYmxlbSBhbmQgdW5uZWNlc3Nhcnkgb3ZlcmhlYWQu DQoNCg0KVGhlIHByb2JsZW0gaXMgdGhhdCBldmVyeXdoZXJlIGluIE9MU1J2MiB3ZSBhcmUgY2Fy ZWZ1bCB0byBlbnN1cmUgdGhhdCBwYXJhbWV0ZXJzIGNhbiBiZSBpbmRlcGVuZGVudGx5IHNldCwg YW5kIHRoYXQgcm91dGVycyBkb24ndCBuZWVkIHRvIGNvb3JkaW5hdGUgdG8gaW50ZXJvcGVyYXRl LiAoVGhleSBtYXkgZG8gYmV0dGVyIGlmIHRoZXkgZG8sIGJ1dCB0aGF0J3MgYSByZWZpbmVtZW50 LikgSGVyZSB5b3UgYXJlIHVzaW5nIGFuIFNSX0hPTERfVElNRV9NVUxUSVBMSUVSIHRoYXQgdGhl IHJlY2VpdmVyIGhhcyB0byBrbm93IGlzIHdoYXQgdGhlIHNlbmRlciBpbnRlbmRzLiBBbmQgaXQn cyB1bm5lY2Vzc2FyeS4gSWYgYWxsIHRoYXQncyBpbiB0aGUgVEMgbWVzc2FnZSBpcyB0aGUgU09V UkNFX1JPVVRFIFRMViwgeW91IGNhbiBqdXN0IGdpdmUgdGhhdCBhIGxvbmdlciB2YWxpZGl0eSB0 aW1lLCBiZWNhdXNlIHRoZSBvbmx5IHRoaW5nIHRoYXQgdmFsaWRpdHkgdGltZSB3aWxsIGltcGFj dCBvbiBpcyB0aGUgc291cmNlIHJvdXRpbmcgc3RhdHVzLiBJZiB0aGUgcm91dGVyIGlzIGFsc28g c2VuZGluZyBub3JtYWwgVEMgbWVzc2FnZXMgYW5kIHlvdSBzZW5kIHNlcGFyYXRlIFNPVVJDRV9S T1VURSBUTFYgVEMgbWVzc2FnZXMgdGhlbiB0aGF0IHdvdWxkIHN0aWxsIGJlIHNvLiBCdXQgdGhh dCdzIGluZWZmaWNpZW50LCBiZWNhdXNlIGlmIHRoZSByb3V0ZXIgaXMgYWxyZWFkeSBzZW5kaW5n IFRDIG1lc3NhZ2VzLCB3aHkgc2VuZCBzZXBhcmF0ZSBvbmVzIHdpdGggYWRkZWQgb3ZlcmhlYWQs IHdoZW4geW91IGNhbiBwdXQgdGhlIFNPVVJDRV9ST1VURSBUTFYgaW4gdGhlIHNhbWUgVEMgbWVz c2FnZT8gVGhhdCB3b3VsZCB0aGVuICh3aXRob3V0IFNSX0hPTERfVElNRV9NVUxUSVBMSUVSLCBi dXQgdGhhdCdzIGEgZ29vZCB0aGluZyBiZWNhdXNlIFNSX0hPTERfVElNRV9NVUxUSVBMSUVSIGlz IG5vdCBnb29kKSBnaXZlIGEgc2hvcnRlciB2YWxpZGl0eSB0aW1lIHRvIHRoZSBTT1VSQ0VfUk9V VEUgVExWLCBidXQgdGhhdCdzIGZpbmUsIGJlY2F1c2UgdGhhdCByb3V0ZXIgd2lsbCBiZSBzZW5k aW5nIG1vcmUgVEMgbWVzc2FnZXMgd2l0aGluIHRoYXQgdGltZXNjYWxlIGFueXdheS4gRnVydGhl cm1vcmUsIHRoaXMgYWxzbyBhbGxvd3MgdGhlIHJvdXRlciB0aGF0J3Mgc2VuZGluZyBUQyBtZXNz YWdlcyBtb3JlIGZyZXF1ZW50bHkgdG8gcHJvdmlkZSBpdHMgaW5mb3JtYXRpb24gbW9yZSByZXNw b25zaXZlbHkgaW4gdGhlIGNhc2VzIG9mIG5vZGVzIGpvaW5pbmcgYW5kIG5ldHdvcmtzIHJlYXNz ZW1ibGluZy4NCg0KDQpUaGF0IGdpdmVzIHR3byBiZWhhdmlvdXJzOiByb3V0ZXJzIHNlbmRpbmcg VEMgbWVzc2FnZXMgYW55d2F5LCBqdXN0IGFkZCBhIFNPVVJDRV9ST1VURSBUTFYsIGFuZCByb3V0 ZXJzIG5vdCBzZW5kaW5nIFRDIG1lc3NhZ2VzIG90aGVyd2lzZSwganVzdCBpbmNsdWRlIGEgU09V UkNFX1JPVVRFIFRMViBhbmQgc2V0IHRoZSB2YWxpZGl0eSB0aW1lIGFjY29yZGluZyB0byB3aGF0 IHNjaGVkdWxlIHRoYXQgcm91dGVyIGNob29zZXMgdG8gdXNlIC0gd2hpY2ggY2FuIGJlIGF0IHRo ZSBzYW1lIHJhdGUgYXMgdGhlIG90aGVyIHJvdXRlcnMsIG9yIGF0IGEgc2xvd2VyIHJvdXRlLCBv ciAoYSBuZXcgY2FwYWJpbGl0eSB5b3UgZG9uJ3QgaGF2ZSkgc2xvd2x5LCBleGNlcHQgaWYgeW91 IGxlYXJuIG9mIHRoZSBleGlzdGVuY2Ugb2YgYSBuZXcgcm91dGVyIGluIHRoZSBuZXR3b3JrIHlv dSBjYW4gc2VuZCBvbmUgb3IgbW9yZSByZXNwb25zaXZlIFNPVVJDRV9ST1VURSBUTFYgb25seSBU TFZzIHRvIGVuYWJsZSB0aGF0IG5ldyByb3V0ZXIgKG9yIHJvdXRlcnMpIHRvIGxlYXJuIG9mIHRo ZSBzb3VyY2Ugcm91dGluZyBxdWlja2VyLg0KDQoNCkl0J3MgYWxsIHdpbjogY29tYmluaW5nIG1l c3NhZ2VzLCBzb3VyY2Ugc2V0IGNvbnRyb2wsIGFiaWxpdHkgdG8gZG8gbW9yZSBjbGV2ZXIgdGhp bmdzIGlmIHlvdSB3YW50IHRvLiAoWW91IGNvdWxkIHByb2JhYmx5ICBldmVuIHN0aWxsIHNlbmQg c2VwYXJhdGUgVEMgbWVzc2FnZXMgd2l0aCBhIFNPVVJDRV9ST1VURSBUTFYgd2hlbiBhbHNvIHNl bmRpbmcgbm9ybWFsIFRDIG1lc3NhZ2VzIGlmIHlvdSByZWFsbHkgd2FudGVkIHRvLCBhcyBhbiBv cHRpb24gSSBjYW4ndCBzZWUgd2FudGluZyB0byB1c2UgLSBhbHRob3VnaCBpdCBtaWdodCBpbnRy b2R1Y2UgYSBtaW5vciBwcm9ibGVtIHRoYXQgSSBoYXZlbid0IHdvcmtlZCB0aHJvdWdoIHRoZSBP TFNSdjIgc3BlY2lmaWNhdGlvbiB0byBjaGVjaywgYmVjYXVzZSBpdCdzIHVubmVjZXNzYXJ5LikN Cg0KDQpUaGUgcG9pbnQgaXMgdGhhdCB3aGF0IEkgc3VnZ2VzdCBjYW4gZ2FpbiBldmVyeXRoaW5n IHlvdSBkbywgYW5kIGFsbG93IG1vcmUsIHBsdXMgbm90IGJyZWFraW5nIGV4cGVjdGVkIE9MU1J2 MiBiZWhhdmlvdXIuDQoNCg0KOC4zIHNlY29uZCBidWxsZXQuIFlvdSBzaG91bGQgaGVyZSAoYW5k IHBvc3NpYmx5IGVsc2V3aGVyZSkgZXhjbHVkZSByb3V0ZXJzIHdpdGggcm91dGluZyB3aWxsaW5n bmVzcyB6ZXJvLg0KDQoNCg0KOC4zIHRoZXJlIHNlZW1zIHRvIGJlIGFuIGluY29uc2lzdGVuY3ku IFdoZW4gb3BlcmF0aW5nIHByb2FjdGl2ZWx5IGFuZCBubyBtdWx0aXBsZSByb3V0ZXMsIGRyb3Ag dGhlIHBhY2tldCwgYnV0IHJlYWN0aXZlbHkgdXNlIHN0YW5kYXJkIHJvdXRpbmcuIFRoZSBsYXR0 ZXIgc2VlbXMgbW9yZSBhcHByb3ByaWF0ZSBpbiB0aGUgZm9ybWVyIGNhc2UgYWxzby4NCg0KOSBD VVRPRkZfUkFUSU8uIEluc2lzdHMgb2Ygc3RyaWN0bHksIGJ1dCBhcyBkZWZpbmVkIGVhcmxpZXIs IG1heSBiZSA+PSAxYC4NCg0KQWxsIGZpeGVkLg0KDQpUaGFua3MgYWdhaW4gZm9yIHRoZSB2YWx1 YWJsZSBjb21tZW50cyENCg0KYmVzdA0KDQpKaWF6aQ0KDQoNCg0KLS0NCkNocmlzdG9waGVyIERl YXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIElu dGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCl9fX18NCg0KVDogICs0NCAz MzAwIDQ2NzUwMCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1z Zm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJh ZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRl ZCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcw0KTm86IDAxMzM3NDUxIFJlZ2lzdGVyZWQg T2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLA0KU3VycmV5LCBHVTIgN1lQ DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1hbmV0IFttYWlsdG86bWFu ZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRoZSBJRVNHDQpTZW50OiAyMCBBcHJp bCAyMDE3IDIyOjUxDQpUbzogSUVURi1Bbm5vdW5jZQ0KQ2M6IG1hbmV0QGlldGYub3JnPG1haWx0 bzptYW5ldEBpZXRmLm9yZz47IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aEBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoQGlldGYub3JnPjsN Cm1hbmV0LWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bWFuZXQtY2hhaXJzQGlldGYub3JnPg0KU3Vi amVjdDogW21hbmV0XSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBh dGgtMTIudHh0Pg0KKE11bHRpLXBhdGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsg U3RhdGUgUm91dGluZyBQcm90b2NvbA0KdmVyc2lvbiAyIChPTFNSdjIpKSB0byBFeHBlcmltZW50 YWwgUkZDDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5p c2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVy bmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkg bGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93IHRoZSAnUmVwb3J0 IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBv biByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCioqKiBXQVJOSU5HICoq Kg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRl IG91ciBvcmdhbml6YXRpb24uDQoNCg0KVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBm cm9tIHRoZSBNb2JpbGUgQWQtaG9jIE5ldHdvcmtzIFdHDQoobWFuZXQpIHRvIGNvbnNpZGVyIHRo ZSBmb2xsb3dpbmcgZG9jdW1lbnQ6DQotICdNdWx0aS1wYXRoIEV4dGVuc2lvbiBmb3IgdGhlIE9w dGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wNCiB2ZXJzaW9uIDIgKE9MU1J2Mikn DQo8ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEyLnR4dD4gYXMgRXhwZXJpbWVu dGFsIFJGQw0KDQpUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQg ZmV3IHdlZWtzLCBhbmQgc29saWNpdHMgZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBs ZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZSBpZXRmQGlldGYub3JnPG1haWx0 bzppZXRmQGlldGYub3JnPiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTctMDUtMDQuIEV4Y2VwdGlvbmFs bHksIGNvbW1lbnRzIG1heSBiZSBzZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0 Zi5vcmc+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBiZWdpbm5p bmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCg0KQWJz dHJhY3QNCg0KDQogVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBtdWx0aS1wYXRoIGV4dGVuc2lv biBmb3IgdGhlIE9wdGltaXplZCBMaW5rDQogU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9u IDIgKE9MU1J2MikgdG8gZGlzY292ZXIgbXVsdGlwbGUNCiBkaXNqb2ludCBwYXRocywgc28gYXMg dG8gaW1wcm92ZSByZWxpYWJpbGl0eSBvZiB0aGUgT0xTUnYyIHByb3RvY29sLg0KIFRoZSBpbnRl cm9wZXJhYmlsaXR5IHdpdGggT0xTUnYyIGlzIHJldGFpbmVkLg0KDQoNCg0KDQpUaGUgZmlsZSBj YW4gYmUgb2J0YWluZWQgdmlhDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgvDQoNCklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUg dHJhY2tlZCB2aWENCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt bWFuZXQtb2xzcnYyLW11bHRpcGF0aC9iYWwNCmxvdC8NCg0KDQpObyBJUFIgZGVjbGFyYXRpb25z IGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5n IGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVk DQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBh bmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBm b3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE633147CGLKXM0003vGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtdGFiLXNw YW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0 ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBwb2ludCAzIHNob3Vs ZCBiZSDigJxtYXnigJ0gcmF0aGVyIHRoYW4g4oCcd2lsbOKAnSwgYnV0IG90aGVyd2lzZSBnb29k LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpw PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdF N0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxi cj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3 RDdEN0QiPjogJm5ic3A7JiM0Mzs0NCAzMzAwIDQ2NzUwMCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8 L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN MiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3 NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5 MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1 cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBKaWF6aSBZaSBbbWFpbHRvOmlldGZAamlheml5aS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMTAgTWF5IDIwMTcgMTM6NDE8YnI+DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJp c3RvcGhlciAoVUspPGJyPg0KPGI+Q2M6PC9iPiBpZXRmQGlldGYub3JnOyBtYW5ldEBpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoQGlldGYub3JnOyBtYW5ldC1jaGFp cnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTGFzdCBDYWxsOiAm bHQ7ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEyLnR4dCZndDsgKE11bHRpLXBh dGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2Nv bCB2ZXJzaW9uIDIgKE9MU1J2MikpIHRvIEV4cGVyaW1lbnRhbCBSRkM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoy LjBwdCAyLjBwdCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7YmFj a2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy Ij4qKiogV0FSTklORyAqKio8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0O3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPGVtPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+VGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFs IHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Db25zaWRlciBjYXJl ZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0 YWNobWVudHMgb3IgcmVwbHkuPC9zcGFuPjwvZW0+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgaW5m b3JtYXRpb24gcmVnYXJkaW5nIDwvc3Bhbj4NCjwvZW0+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwv c3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPiB0aGF0 IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwNCiBjbGljayA8YSBo cmVmPSJodHRwOi8vd3Mtc2l0ZXMuZW50LmJhZXN5c3RlbXMuY29tL3NpdGVzL0hPU0VDU3Rkc0xp YnJhcnkvU3RhbmRhcmRzTGlicmFyeS9FdmVyeW9uZS9SZWQlMjBGbGFncy5wZGYiPg0KaGVyZTwv YT4uPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy Ij48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPklmIHlvdSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3Vz LCBwbGVhc2UgZm9sbG93DQo8YSBocmVmPSJodHRwOi8vd3Mtc2l0ZXMuZW50LmJhZXN5c3RlbXMu Y29tL3NpdGVzL0hPU0VDU3Rkc0xpYnJhcnkvU3RhbmRhcmRzTGlicmFyeS9FdmVyeW9uZS9EZWFs aW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmIj4NCnRoaXMgcHJvY2VzczwvYT4u PC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz MzM5NzIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGkgQ2hyaXMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCBpdCBtYWtlcyBzZW5zZS4gU28gdGhl IHBvbGljeSB3aWxsIGJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+LSB0aGUgU09VUkNFX1JPVVRFIFRMViB3b27igJl0IGhhdmUgYW55IHZhbHVlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i YXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+LSBFdmVyeSBUQyBtZXNzYWdlIG9yaWdp bmF0ZWQgYnkgdGhlIHNvdXJjZS1yb3V0ZSBzdXBwb3J0ZWQgcm91dGVycyB3aWxsIGhhdmUgYSBT T1VSQ0VfUk9VVEUgVExWPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ LSBUaGUgVEMgbWVzc2FnZSBub3QgY29udGFpbmluZyBhbnkgbmVpZ2hib3VyIGFkZHJlc3Mgd2ls bCBoYXZlIGEgbG9uZ2VyIHZhbGlkaXR5IHRpbWUgY29tcGFyZWQgdG8gT0xTUnYyIG5vcm1hbCBU QyBtZXNzYWdlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YmVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KaWF6aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDEwIE1heSAyMDE3LCBhdCAxMTozMywgRGVhcmxvdmUsIENocmlz dG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+QWRkaXRpb25hbCBjb21tZW50cyAmZ3Q7Jmd0OyZndDsgYmVsb3cuIFdoYXQgSSdtIHBy b3Bvc2luZyAoc3BlbGxlZCBvdXQgYSBiaXQgbW9yZSkgaXMgYWxsIHdpbiwgYW5kIHJlbW92ZXMg cHJvYmxlbXMgd2l0aCB0aGUgY3VycmVudCBkZXNpZ24uIEkgdGhpbmsgdGhpcyBpcyBhIG11c3Qg ZG8uPGJyPg0KPGJyPg0KLS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyPg0KQ2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFs IEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9y aWVzPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQpUOiAmbmJzcDsmIzQzOzQ0IDMz MDAgNDY3NTAwICZuYnNwO3wgJm5ic3A7RTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBi YWVzeXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3Jk IFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhO Ljxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQg SW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2Fs ZXMgTm86IDAxMzM3NDUxPGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQ YXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUDxicj4NCjxicj4NCjxicj4NCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSmlhemkgWWkgWzwvc3Bhbj48YSBocmVmPSJt YWlsdG86aWV0ZkBqaWF6aXlpLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFp bHRvOmlldGZAamlheml5aS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KU2VudDogMDkgTWF5IDIwMTcgMjM6NDk8YnI+DQpUbzogRGVhcmxvdmUsIENocmlzdG9waGVy IChVSyk8YnI+DQpDYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5pZXRmQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij47IElFVEYtQW5ub3VuY2U7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1hbmV0QGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGhAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYW5ldC1j aGFpcnNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1hbmV0LWNoYWly c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K U3ViamVjdDogUmU6IFttYW5ldF0gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1tYW5ldC1vbHNy djItbXVsdGlwYXRoLTEyLnR4dCZndDsgKE11bHRpLXBhdGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0 aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDIgKE9MU1J2MikpIHRv IEV4cGVyaW1lbnRhbCBSRkM8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJO SU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t IG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5l ciBvciBmcm9tIHRoZSBpbnRlcm5ldC48YnI+DQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5 b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw bHkuPGJyPg0KRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElU IG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBt ZXNzYWdlcy48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCkhpIENocmlzLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpUaGFua3MgYSBsb3QgZm9yIHRo ZSBjb21tZW50cyEgUGxlYXNlIGNoZWNrIG91ciByZXBseSBpbmxpbmU6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiciBzdHlsZT0iZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9u IDkgTWF5IDIwMTcsIGF0IDEyOjEzLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCkEgZmV3IGNvbW1lbnRz IG9uIHRoaXMgZHJhZnQuPGJyPg0KPGJyPg0KSVB2NiBzcGVjaWZpZXMgY29tcGxldGUgc291cmNl IHJvdXRpbmcuIEJ1dCB0aGlzIHNwZWNpZmljYXRpb24gY2FuIG9ubHkgY29uc2lkZXIgd2hhdCBo YXBwZW5zIHdpdGhpbiB0aGUgTUFORVQuIFNvIGZvciBhIHBhY2tldCBmcm9tIHNvbWV3aGVyZSBp biB0aGUgTUFORVQgdG8gc29tZXdoZXJlIHdlbGwgb3V0c2lkZSB0aGUgTUFORVQsIHRoZSBwYWNr ZXQgbXVzdCBiZSBzb3VyY2Ugcm91dGVkIHRvIHRoZSBnYXRld2F5IGJldHdlZW4gTUFORVQgYW5k DQogcmVzdCBvZiBJbnRlcm5ldCwgYW5kIG5vdCBzb3VyY2Ugcm91dGVkIGFmdGVyIHRoYXQuIFRo aXMgSSB0aGluayBzaG91bGQgYmUgZXhwbGljaXRseSBtZW50aW9uZWQuIFdoZXRoZXIgdGhhdCBp cyBjb25zaWRlcmVkIGNvbXBsaWFudCB3aXRoIElQdjYgSSBsZWF2ZSB0byBvdGhlcnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGJyPg0KR29vZCBwb2ludC4gV2UgYWRkZWQgc29tZSB0ZXh0IGF0IHRoZSBl bmQgb2Ygc2VjdGlvbiA4LjQmcXVvdDsgRGF0YWdyYW0gUHJvY2Vzc2luZyBhdCB0aGUgTVAtT0xT UnYyIE9yaWdpbmF0b3ImcXVvdDs8YnI+DQo8YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo3LjEgU1JfYWRk ciB3b3VsZCBiZXR0ZXIgc2F5ICZxdW90O29yaWdpbmF0b3ImcXVvdDsgYWRkcmVzcyByYXRoZXIg dGhhbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+ DQomcXVvdDtuZXR3b3JrJnF1b3Q7IGFkZHJlc3MuIChUaGF0IG1ha2VzIGl0IGFuIGFkZHJlc3Mg d2l0aG91dCBhIG5ldG1hc2ssIHNlZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQpSRkMgNzE4MS4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KZml4 ZWQuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KOC4xIFRo aXMgaXMgc3VnZ2VzdGluZyBjcmVhdGluZyBUQyBtZXNzYWdlcyB0aGF0IGhhdmUgb24gbmVpZ2hi b3VyIGFkZHJlc3NlcyBidXQgaGF2ZSBvbmx5IGEgU09VUkNFX1JPVVRFIFRMVi4gVGhpcyBpcyBu b3QgdGhlIGRlc2lnbiBJIHdvdWxkIGhhdmUgc3VnZ2VzdGVkIGFzIGNvbnNpc3RlbnQgd2l0aCBo b3cgSSB3b3VsZCBleHBlY3QgYW4gZXh0ZW5zaW9uIHRvIE9MU1J2MiB0byBkbyB0aGluZ3MuIFdl IG5lZWQgdG8gY29uc2lkZXIgdHdvIGtpbmRzDQogb2Ygcm91dGVyczogdGhvc2Ugc2VuZGluZyBU QyBtZXNzYWdlcyBhbnl3YXksIHRob3NlIHRoYXQgKG90aGVyIHRoYW4gdGhpcyBleHRlbnNpb24p IGRvIG5vdC4gSW4gdGhlIGZvcm1lciBjYXNlIHlvdSBjb3VsZCBqdXN0IGFkZCB0aGUgU09VUkNF X1JPVVRFIFRMViB0byB0aG9zZSBUQyBtZXNzYWdlcyBpdCBzZW5kcy4gVGhlbiB0aGF0IGluZm9y bWF0aW9uIGlzIG1haW50YWluZWQgdXAgdG8gZGF0ZS4gUm91dGVycyB0aGF0IGRvbid0IHVzdWFs bHkNCiBzZW5kIFRDIG1lc3NhZ2VzIGNvdWxkIHNlbmQgVEMgbWVzc2FnZXMgd2l0aCBqdXN0IHRo YXQgVExWLiBCdXQgdGhlbiB0aGVyZSdzIGFuIGlzc3VlIG92ZXIgdmFsaWRpdHkgdGltZS4gQSBw YXJhbWV0ZXIgU1JfSE9MRF9USU1FX01VTFRJUExJRVIgaXMgaW50cm9kdWNlZC4gVGhlcmUncyBu byBuZWVkIGZvciB0aGF0IC0geW91IGNhbiBzaW1wbHkgaW5jb3Jwb3JhdGUgdGhhdCBpbnRvIHRo ZSB2YWxpZGl0eSB0aW1lIHJlY29yZGVkIGluIHRoZSBtZXNzYWdlLg0KIFRoYXQgYXZvaWRzIGEg bmVlZCB0byBoYW5kbGUgdGhlIHR3byBjYXNlcyBvZiByb3V0ZXJzIGRpZmZlcmVudGx5LiBUaGVy ZSBpcyB0aGVuIGFuIG9kZGl0eSB0aGF0IHlvdSBnZXQgc29tZSByb3V0ZXJzIHNlbmRpbmcgVEMg bWVzc2FnZXMgd2l0aCBub3JtYWwgdmFsaWRpdHkgdGltZXMgYW5kIGFkZHJlc3NlcywgYW5kIHNv bWUgdGhhdCBjYW4gYmUgc2VudCBsZXNzIGZyZXF1ZW50bHkgd2l0aCBubyBhZGRyZXNzZXMgYW5k IGxvbmdlciB2YWxpZGl0eQ0KIHRpbWVzLiBCdXQgdGhhdCdzIHN1c3BlY3QgLSBub3RlIHRoYXQg aXQncyBub3QgZG9uZSBpbiBPTFNSdjIgZm9yIGF0dGFjaGVkIG5ldHdvcmtzIChhbm90aGVyIHJl YXNvbiB0byBzZW5kIFRDIG1lc3NhZ2VzIGFsdGhvdWdoIG5vIG5laWdoYm91cnMgbmVlZCByZXBv cnRpbmcpLiBUaGF0J3MgYmVjYXVzZSBsb25nZXIgaW50ZXJ2YWxzIG1ha2UgcmVhY3RpbmcgdG8g bmV3IHJvdXRlcnMgam9pbmluZyAoYW5kIG5ldHdvcmsgcmVhc3NlbWJseSBhZnRlcg0KIGZyYWdt ZW50YXRpb24pIHNsb3cuPGJyPg0KUmF0aGVyIGEgYmV0dGVyIGRlc2lnbiB3b3VsZCBzaW1wbHkg YmUgdG8gYWRkIFNPVVJDRV9ST1VURSBUTFYgdG8gbm9ybWFsIFRDIG1lc3NhZ2VzLiBXaGVuIHNl bmRpbmcgVEMgbWVzc2FnZXMgZm9yIGp1c3QgdGhhdCByZWFzb24sIHRoYXQgY291bGQgYmUganVz dCB0aGUgdXN1YWwgY2FzZSwgYnV0IHlvdSBjb3VsZCBhbGxvdyBhcyBhbiBvcHRpb24gaW4gdGhp cyBjYXNlIHRvIHNlbmQgbGVzcyBmcmVxdWVudGx5IHdpdGggdmFsaWRpdHkgdGltZQ0KIGluY3Jl YXNlZCBhY2NvcmRpbmdseS4gV2hlbiBub3QgdXNpbmcgdGhhdCBvcHRpb24sIG9uY2UgYSByb3V0 ZXIgbmVlZHMgdG8gc2VuZCBhIFRDIG1lc3NhZ2UsIGl0IGNvdWxkIHRoZW4gZGVjaWRlIHRvIHJl cG9ydCBuZWlnaGJvdXJzLCBpbmNyZWFzaW5nIHRoZSB0b3BvbG9neSBkaXN0cmlidXRlZCBhbmQg YWxsb3dpbmcgbW9yZSByb3V0ZXMsIHRoaXMgYWxzbyBiZWluZyBhbiBvcHRpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGJyPg0KSUlSQywgd2UgaGFkIGEgbG9uZyBkaXNjdXNzaW9uIG9uIHRoaXMgaXNz dWUgYW5kIHByb2R1Y2VkIHRoZSBjdXJyZW50IHRleHQuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NClRoZSBwdXJwb3NlIGlzIHRvIGlkZW50aWZ5 IHRoZSByb3V0ZXJzIHRoYXQgZG9u4oCZdCBzZW5kIFRDIG1lc3NhZ2VzIGJ1dCBzdXBwb3J0IHNv dXJjZSByb3V0aW5nLiBUbyBhdm9pZCB1bm5lY2Vzc2FyeSBUQyBmbG9vZGluZywgdGhlIGludGVy dmFsIGlzIG11Y2ggbG9uZ2VyIHRoYW4gdGhlIG5vcm1hbCBUQyBpbnRlcnZhbC48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KVGhlIG5vcm1hbCBU QyBtZXNzYWdlcyAoZ2VuZXJhdGVkIGJhc2VkIG9uIFJGQzcxODEpIGFsd2F5cyBoYXZlIGEgU09V UkNFX1JPVVRFIFRMVi4gQnV0IGlmIHdlIHVzZSB0aGUgc2FtZSB2YWxpZGl0eSB0aW1lIGZvciBi b3RoIFJGQzcxODEgbm9ybWFsIFRDIHByb2Nlc3NpbmcgYW5kIE1QLU9MU1J2MiBTUl9ST1VURSBU TFYgcHJvY2Vzc2luZywgdGhlIHZhbGlkIHRpbWUgaW4gdGhlIFNSLU9MU1J2MiBSb3V0ZXIgU2V0 IHdvdWxkIGJlIG11Y2ggc2hvcnRlcg0KIHRoYW4gZXhwZWN0ZWQuIEEgcG9zc2libGUgY2FzZSBp cyB0aGF0LCB0aGUgcm91dGVyIHN0b3BzIHNlbmRpbmcgbm9ybWFsIFRDIG1lc3NhZ2VzLCB0aGUg Y29ycmVzcG9uZGluZyBlbnRyeSBpbiB0aGUgU1ItT0xTUnYyIFJvdXRlciBzZXQgd2lsbCBzb29u IGV4cGlyZS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KVGhlcmVmb3JlLCBJIHRoaW5rIGl04oCZcyByZWFzb25hYmxlIHRvIG1ha2UgdXNlIG9m IHRoZSBTUl9IT0xEX1RJTUVfTVVMVElQTElFUiB0byBkaXN0aW5ndWlzaCB0aGUgdmFsaWQgdGlt ZSBvZiBub3JtYWwgVEMgbWVzc2FnZSBpbmZvcm1hdGlvbiBhbmQgU1JfUk9VVEUgaW5mb3JtYXRp b24uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGRvbid0IGFncmVlLCBhbmQgSSB0aGluayB3aGF0IHlvdSBh cmUgc3VnZ2VzdGluZyBpbnRyb2R1Y2VzIGEgcHJvYmxlbSBhbmQgdW5uZWNlc3Nhcnkgb3Zlcmhl YWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyIHN0 eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlRoZSBwcm9ibGVtIGlzIHRoYXQgZXZlcnl3aGVyZSBpbiBPTFNSdjIgd2Ug YXJlIGNhcmVmdWwgdG8gZW5zdXJlIHRoYXQgcGFyYW1ldGVycyBjYW4gYmUgaW5kZXBlbmRlbnRs eSBzZXQsIGFuZCB0aGF0IHJvdXRlcnMgZG9uJ3QgbmVlZCB0byBjb29yZGluYXRlIHRvIGludGVy b3BlcmF0ZS4gKFRoZXkNCiBtYXkgZG8gYmV0dGVyIGlmIHRoZXkgZG8sIGJ1dCB0aGF0J3MgYSBy ZWZpbmVtZW50LikgSGVyZSB5b3UgYXJlIHVzaW5nIGFuIFNSX0hPTERfVElNRV9NVUxUSVBMSUVS IHRoYXQgdGhlIHJlY2VpdmVyIGhhcyB0byBrbm93IGlzIHdoYXQgdGhlIHNlbmRlciBpbnRlbmRz LiBBbmQgaXQncyB1bm5lY2Vzc2FyeS4gSWYgYWxsIHRoYXQncyBpbiB0aGUgVEMgbWVzc2FnZSBp cyB0aGUgU09VUkNFX1JPVVRFIFRMViwgeW91IGNhbiBqdXN0IGdpdmUgdGhhdA0KIGEgbG9uZ2Vy IHZhbGlkaXR5IHRpbWUsIGJlY2F1c2UgdGhlIG9ubHkgdGhpbmcgdGhhdCB2YWxpZGl0eSB0aW1l IHdpbGwgaW1wYWN0IG9uIGlzIHRoZSBzb3VyY2Ugcm91dGluZyBzdGF0dXMuIElmIHRoZSByb3V0 ZXIgaXMgYWxzbyBzZW5kaW5nIG5vcm1hbCBUQyBtZXNzYWdlcyBhbmQgeW91IHNlbmQgc2VwYXJh dGUgU09VUkNFX1JPVVRFIFRMViBUQyBtZXNzYWdlcyB0aGVuIHRoYXQgd291bGQgc3RpbGwgYmUg c28uIEJ1dCB0aGF0J3MgaW5lZmZpY2llbnQsDQogYmVjYXVzZSBpZiB0aGUgcm91dGVyIGlzIGFs cmVhZHkgc2VuZGluZyBUQyBtZXNzYWdlcywgd2h5IHNlbmQgc2VwYXJhdGUgb25lcyB3aXRoIGFk ZGVkIG92ZXJoZWFkLCB3aGVuIHlvdSBjYW4gcHV0IHRoZSBTT1VSQ0VfUk9VVEUgVExWIGluIHRo ZSBzYW1lIFRDIG1lc3NhZ2U/IFRoYXQgd291bGQgdGhlbiAod2l0aG91dCBTUl9IT0xEX1RJTUVf TVVMVElQTElFUiwgYnV0IHRoYXQncyBhIGdvb2QgdGhpbmcgYmVjYXVzZSBTUl9IT0xEX1RJTUVf TVVMVElQTElFUg0KIGlzIG5vdCBnb29kKSBnaXZlIGEgc2hvcnRlciB2YWxpZGl0eSB0aW1lIHRv IHRoZSBTT1VSQ0VfUk9VVEUgVExWLCBidXQgdGhhdCdzIGZpbmUsIGJlY2F1c2UgdGhhdCByb3V0 ZXIgd2lsbCBiZSBzZW5kaW5nIG1vcmUgVEMgbWVzc2FnZXMgd2l0aGluIHRoYXQgdGltZXNjYWxl IGFueXdheS4gRnVydGhlcm1vcmUsIHRoaXMgYWxzbyBhbGxvd3MgdGhlIHJvdXRlciB0aGF0J3Mg c2VuZGluZyBUQyBtZXNzYWdlcyBtb3JlIGZyZXF1ZW50bHkgdG8gcHJvdmlkZQ0KIGl0cyBpbmZv cm1hdGlvbiBtb3JlIHJlc3BvbnNpdmVseSBpbiB0aGUgY2FzZXMgb2Ygbm9kZXMgam9pbmluZyBh bmQgbmV0d29ya3MgcmVhc3NlbWJsaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0 LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6 MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGF0IGdpdmVzIHR3byBiZWhhdmlv dXJzOiByb3V0ZXJzIHNlbmRpbmcgVEMgbWVzc2FnZXMgYW55d2F5LCBqdXN0IGFkZCBhIFNPVVJD RV9ST1VURSBUTFYsIGFuZCByb3V0ZXJzIG5vdCBzZW5kaW5nIFRDIG1lc3NhZ2VzIG90aGVyd2lz ZSwganVzdCBpbmNsdWRlIGEgU09VUkNFX1JPVVRFIFRMVg0KIGFuZCBzZXQgdGhlIHZhbGlkaXR5 IHRpbWUgYWNjb3JkaW5nIHRvIHdoYXQgc2NoZWR1bGUgdGhhdCByb3V0ZXIgY2hvb3NlcyB0byB1 c2UgLSB3aGljaCBjYW4gYmUgYXQgdGhlIHNhbWUgcmF0ZSBhcyB0aGUgb3RoZXIgcm91dGVycywg b3IgYXQgYSBzbG93ZXIgcm91dGUsIG9yIChhIG5ldyBjYXBhYmlsaXR5IHlvdSBkb24ndCBoYXZl KSBzbG93bHksIGV4Y2VwdCBpZiB5b3UgbGVhcm4gb2YgdGhlIGV4aXN0ZW5jZSBvZiBhIG5ldyBy b3V0ZXIgaW4NCiB0aGUgbmV0d29yayB5b3UgY2FuIHNlbmQgb25lIG9yIG1vcmUgcmVzcG9uc2l2 ZSBTT1VSQ0VfUk9VVEUgVExWIG9ubHkgVExWcyB0byBlbmFibGUgdGhhdCBuZXcgcm91dGVyIChv ciByb3V0ZXJzKSB0byBsZWFybiBvZiB0aGUgc291cmNlIHJvdXRpbmcgcXVpY2tlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnIgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SXQncyBhbGwgd2luOiBjb21iaW5pbmcgbWVzc2FnZXMsIHNvdXJjZSBzZXQgY29udHJvbCwg YWJpbGl0eSB0byBkbyBtb3JlIGNsZXZlciB0aGluZ3MgaWYgeW91IHdhbnQgdG8uIChZb3UgY291 bGQgcHJvYmFibHkgJm5ic3A7ZXZlbiBzdGlsbCBzZW5kIHNlcGFyYXRlIFRDIG1lc3NhZ2VzIHdp dGggYSBTT1VSQ0VfUk9VVEUNCiBUTFYgd2hlbiBhbHNvIHNlbmRpbmcgbm9ybWFsIFRDIG1lc3Nh Z2VzIGlmIHlvdSByZWFsbHkgd2FudGVkIHRvLCBhcyBhbiBvcHRpb24gSSBjYW4ndCBzZWUgd2Fu dGluZyB0byB1c2UgLSBhbHRob3VnaCBpdCBtaWdodCBpbnRyb2R1Y2UgYSBtaW5vciBwcm9ibGVt IHRoYXQgSSBoYXZlbid0IHdvcmtlZCB0aHJvdWdoIHRoZSBPTFNSdjIgc3BlY2lmaWNhdGlvbiB0 byBjaGVjaywgYmVjYXVzZSBpdCdzIHVubmVjZXNzYXJ5Lik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHBvaW50IGlz IHRoYXQgd2hhdCBJIHN1Z2dlc3QgY2FuIGdhaW4gZXZlcnl0aGluZyB5b3UgZG8sIGFuZCBhbGxv dyBtb3JlLCBwbHVzIG5vdCBicmVha2luZyBleHBlY3RlZCBPTFNSdjIgYmVoYXZpb3VyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiciBzdHlsZT0iZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjguMyBzZWNvbmQgYnVsbGV0LiBZb3Ugc2hvdWxkIGhlcmUgKGFuZCBwb3NzaWJseSBlbHNld2hl cmUpIGV4Y2x1ZGUgcm91dGVycyB3aXRoIHJvdXRpbmcgd2lsbGluZ25lc3MgemVyby48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGln bjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+ DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo4LjMgdGhlcmUgc2VlbXMgdG8gYmUgYW4g aW5jb25zaXN0ZW5jeS4gV2hlbiBvcGVyYXRpbmcgcHJvYWN0aXZlbHkgYW5kIG5vIG11bHRpcGxl IHJvdXRlcywgZHJvcCB0aGUgcGFja2V0LCBidXQgcmVhY3RpdmVseSB1c2Ugc3RhbmRhcmQgcm91 dGluZy4gVGhlIGxhdHRlciBzZWVtcyBtb3JlIGFwcHJvcHJpYXRlIGluIHRoZSBmb3JtZXIgY2Fz ZSBhbHNvLjxicj4NCjxicj4NCjkgQ1VUT0ZGX1JBVElPLiBJbnNpc3RzIG9mIHN0cmljdGx5LCBi dXQgYXMgZGVmaW5lZCBlYXJsaWVyLCBtYXkgYmUgJmd0Oz0gMWAuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KQWxsIGZpeGVkLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQo8YnI+DQpUaGFua3MgYWdhaW4gZm9yIHRoZSB2YWx1YWJsZSBjb21tZW50 cyE8YnI+DQo8YnI+DQpiZXN0PGJyPg0KPGJyPg0KSmlhemk8YnI+DQo8YnIgc3R5bGU9ImZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YnI+DQotLTxicj4NCkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBF bmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmll czxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KX19fXzxicj4NCjxicj4NClQ6ICZuYnNwOyYjNDM7NDQgMzMwMCA0 Njc1MDAgJm5ic3A7fCAmbmJzcDtFOiA8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjxicj4N CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kg UGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhy ZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwv YT48YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkIFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlczxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpObzogMDEzMzc0NTEgUmVnaXN0ZXJlZCBPZmZpY2U6IFN1 cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NClN1cnJleSwgR1UyIDdZUDxicj4NCjxicj4NCjxi cj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogbWFuZXQgWzxhIGhyZWY9 Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bWFuZXQtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUaGUgSUVTRzxicj4NClNlbnQ6IDIwIEFwcmlsIDIwMTcg MjI6NTE8YnI+DQpUbzogSUVURi1Bbm5vdW5jZTxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86bWFu ZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWll dGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aEBpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW1hbmV0LW9s c3J2Mi1tdWx0aXBhdGhAaWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXQtY2hhaXJzQGll dGYub3JnIj5tYW5ldC1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW21hbmV0XSBM YXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTIudHh0Jmd0 OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQoo TXVsdGktcGF0aCBFeHRlbnNpb24gZm9yIHRoZSBPcHRpbWl6ZWQgTGluayBTdGF0ZSBSb3V0aW5n IFByb3RvY29sPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjxicj4NCnZlcnNpb24gMiAoT0xTUnYyKSkgdG8gRXhwZXJpbWVudGFsIFJGQzxicj4NCjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t IFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBl aXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZyb20gdGhlIGludGVybmV0Ljxicj4N CkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtz LCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+DQpGb2xsb3cgdGhlICdSZXBvcnQg U3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9u IHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KKioq IFdBUk5JTkcgKioqPGJyPg0KRVhURVJOQUwgRU1BSUwgLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0 ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbml6YXRpb24uPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElF U0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBNb2JpbGUgQWQtaG9jIE5ldHdvcmtz IFdHPGJyPg0KKG1hbmV0KSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4N Ci0gJ011bHRpLXBhdGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91 dGluZyBQcm90b2NvbDxicj4NCiZuYnNwO3ZlcnNpb24gMiAoT0xTUnYyKSc8YnI+DQombHQ7ZHJh ZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEyLnR4dCZndDsgYXMgRXhwZXJpbWVudGFs IFJGQzxicj4NCjxicj4NClRoZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUg bmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cyBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlv bi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlDQo8YSBocmVmPSJtYWls dG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4gbWFpbGluZyBsaXN0cyBieSAyMDE3 LTA1LTA0LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkgYmUgc2VudCB0bw0KPGEgaHJlZj0i bWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+IGluc3RlYWQuIEluIGVpdGhl ciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0 byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy48YnI+DQo8YnI+DQpBYnN0cmFjdDxicj4NCjxicj4N Cjxicj4NCiZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbXVsdGktcGF0aCBleHRlbnNp b24gZm9yIHRoZSBPcHRpbWl6ZWQgTGluazxicj4NCiZuYnNwO1N0YXRlIFJvdXRpbmcgUHJvdG9j b2wgdmVyc2lvbiAyIChPTFNSdjIpIHRvIGRpc2NvdmVyIG11bHRpcGxlPGJyPg0KJm5ic3A7ZGlz am9pbnQgcGF0aHMsIHNvIGFzIHRvIGltcHJvdmUgcmVsaWFiaWxpdHkgb2YgdGhlIE9MU1J2MiBw cm90b2NvbC48YnI+DQombmJzcDtUaGUgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIE9MU1J2MiBpcyBy ZXRhaW5lZC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpUaGUgZmlsZSBjYW4gYmUgb2J0 YWluZWQgdmlhPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLzwvYT48YnI+DQo8 YnI+DQpJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVs dGlwYXRoL2JhbCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1t YW5ldC1vbHNydjItbXVsdGlwYXRoL2JhbDwvYT48YnI+DQpsb3QvPGJyPg0KPGJyPg0KPGJyPg0K Tm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMg SS1ELjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Ij5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjxicj4NCjxicj4N CioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZy b20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90 IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KZGlzdHJpYnV0 ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE633147CGLKXM0003vGREEN_-- From nobody Wed May 10 07:05:24 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80375129B50; Wed, 10 May 2017 07:05:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149442511446.26213.1760783097572630645@ietfa.amsl.com> Date: Wed, 10 May 2017 07:05:14 -0700 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:05:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Multipath Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-13.txt Pages : 25 Date : 2017-05-10 Abstract: This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13 https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 10 07:15:53 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBD7129B61 for ; Wed, 10 May 2017 07:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AKAjLXiuKeA for ; Wed, 10 May 2017 07:15:49 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDDF129B49 for ; Wed, 10 May 2017 07:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494425744; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=8839; bh=A8CPwQdIIHApIherpSmsYm6TVmsgNjAhm+X/enz4Qc4=; b=B+f2K47cBM/Eezmhzx6Tce3p+X7MiW3hdww2n3lPUi8IzlBzjXMmIK7QYDfJwRyA zWHO+zqiNzXdtoouCy5/oozXFrmRu7QKJ7rFTPLQnG+0ILWEEWxu91ARkts2q6qFrdq +A3AstdcyUxVtiMS2iOI9IWVb24zXs11H/u61yFw= Received: from [129.104.72.106] (129.104.72.106 [129.104.72.106]) by mx.zohomail.com with SMTPS id 1494425744141943.2651793300265; Wed, 10 May 2017 07:15:44 -0700 (PDT) From: Jiazi Yi Message-Id: <8019BB63-45FF-4BF2-84AA-EC117B2D0772@jiaziyi.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_173575C1-4851-416A-BB7D-079CAC4876F3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 16:15:40 +0200 In-Reply-To: <149442511446.26213.1760783097572630645@ietfa.amsl.com> Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "Alvaro Retana (aretana)" , Zhen Cao , Peter Yee , Suresh Krishnan , "Dearlove, Christopher (UK)" To: manet References: <149442511446.26213.1760783097572630645@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 14:15:52 -0000 --Apple-Mail=_173575C1-4851-416A-BB7D-079CAC4876F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all,=20 We just submitted a new revision of the olsrv2-multipath draft based on = the comments received since the IETF LC, mainly from: Chris: https://www.ietf.org/mail-archive/web/manet/current/msg19426.html = Zhen: https://www.ietf.org/mail-archive/web/manet/current/msg19425.html = Mirja: https://www.ietf.org/mail-archive/web/manet/current/msg19424.html = Peter: https://www.ietf.org/mail-archive/web/manet/current/msg19423.html = Alvaro: = https://www.ietf.org/mail-archive/web/manet/current/msg19420.html = Suresh: = https://www.ietf.org/mail-archive/web/manet/current/msg19431.html = We appreciate the review and the comments, which certainly help = improving the quality of the draft a lot. Thanks very much! Further = feedback is welcome.=20 regards Jiazi > On 10 May 2017, at 16:05, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Mobile Ad-hoc Networks of the IETF. >=20 > Title : Multipath Extension for the Optimized Link = State Routing Protocol version 2 (OLSRv2) > Authors : Jiazi Yi > Benoit Parrein > Filename : draft-ietf-manet-olsrv2-multipath-13.txt > Pages : 25 > Date : 2017-05-10 >=20 > Abstract: > This document specifies a multipath extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > The interoperability with OLSRv2 is retained. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13 > = https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-13= >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-13= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_173575C1-4851-416A-BB7D-079CAC4876F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear all, 

We just submitted a new revision of the = olsrv2-multipath draft based on the comments received since the IETF LC, = mainly from:

Chris: https://www.ietf.org/mail-archive/web/manet/current/msg19426.ht= ml
Zhen: https://www.ietf.org/mail-archive/web/manet/current/msg19425.ht= ml
Mirja: https://www.ietf.org/mail-archive/web/manet/current/msg19424.ht= ml
Peter: https://www.ietf.org/mail-archive/web/manet/current/msg19423.ht= ml
Alvaro: https://www.ietf.org/mail-archive/web/manet/current/msg19420.ht= ml
Suresh: https://www.ietf.org/mail-archive/web/manet/current/msg19431.ht= ml


We appreciate the review = and the comments, which certainly help improving the quality of the = draft a lot. Thanks very much! Further feedback is = welcome. 

regards

Jiazi

On 10 May 2017, at 16:05, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Mobile Ad-hoc Networks of the IETF.

=        Title =           : Multipath = Extension for the Optimized Link State Routing Protocol version 2 = (OLSRv2)
=        Authors =         : Jiazi Yi
=             &n= bsp;           &nbs= p;Benoit Parrein
Filename =        : = draft-ietf-manet-olsrv2-multipath-13.txt
Pages =           : 25
= Date =            : = 2017-05-10

Abstract:
=   This document specifies a multipath extension for the = Optimized Link
  State Routing Protocol version = 2 (OLSRv2) to discover multiple
  disjoint = paths, so as to improve reliability of the OLSRv2 protocol.
=   The interoperability with OLSRv2 is retained.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multip= ath/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-1= 3
https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-m= ultipath-13

A diff from the previous = version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mul= tipath-13


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/

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

= --Apple-Mail=_173575C1-4851-416A-BB7D-079CAC4876F3-- From nobody Wed May 10 08:03:53 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528D9129BCC for ; Wed, 10 May 2017 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWOvF1As_UBG for ; Wed, 10 May 2017 08:03:48 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0120F1273B1 for ; Wed, 10 May 2017 08:03:47 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.38,319,1491260400"; d="scan'208,217"; a="62058300" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 10 May 2017 16:03:46 +0100 X-IronPort-AV: E=Sophos;i="5.38,319,1491260400"; d="scan'208,217";a="170748451" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 10 May 2017 16:03:27 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.172]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Wed, 10 May 2017 16:03:27 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi Yi , manet CC: Zhen Cao , Peter Yee , "Suresh Krishnan" , =?iso-8859-1?Q?Mirja_K=FChlewind?= Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt Thread-Index: AQHSyZaBRhUgiyHbekGG9bOYeH0cTqHti90AgAAXDRA= Date: Wed, 10 May 2017 15:03:27 +0000 Message-ID: References: <149442511446.26213.1760783097572630645@ietfa.amsl.com> <8019BB63-45FF-4BF2-84AA-EC117B2D0772@jiaziyi.com> In-Reply-To: <8019BB63-45FF-4BF2-84AA-EC117B2D0772@jiaziyi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE63314D5GLKXM0003vGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:03:51 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE63314D5GLKXM0003vGREEN_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Section 7.1 SR_addr original -> originator. Section 8.1, second paragraph: You can say that because a TC message will b= e created in every TC_INTERVAL, and because SR_TC_INTERVAL >=3D TC_INTERVAL= [you want >=3D, even with a SHOULD for normal behaviour] the normal behav= iour will ensure a TC message with a SOURCE_ROUTE TLV at least every SR_TC_= INTERVAL, there's no need to make it a new requirement. Section 8.1, third paragraph, should I think more clearly say that it is ab= out routers support source routing but would not, according to RFC 7181, se= nd TC messages, but now MUST do so. The MUST NOT applied to neighbour addre= sses arguably isn't, as it's not actually broken for it to do so, but might= advertise neighbours for too long. Perhaps a SHOULD NOT? It could also not= e that if this TC message carries an INTERVAL_TIME TLV (which is optional) = it MUST report SR_TC_INTERVAL. Section 8.2 SR_time. We haven't put in place the condition that we never re= duce validity times in analogous places in RFC 7181, so I don't think that = is needed here. Last line on page 13 route -> routed. Section 9, I think the SR_TC_INTERVAL and SR_HOLD_TIME constraints are a bi= t messy, and missing a constraint. SR_TC_INTERVAL: MUST be greater than or equal to TC_INTERVAL, SHOULD be sig= nificantly greater than TC_INTERVAL, default 10 x TC_INTERVAL. SR_HOLD_TIME: MUST be greater than SR_TC_INTERVAL, SHOULD allow for a small= number of lost messages, default is 3 x SR_TC_INTERVAL. (There's no need t= o directly relate to TC_INTERVAL here.) -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 3300 467500 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi Sent: 10 May 2017 15:16 To: manet Cc: Dearlove, Christopher (UK); Zhen Cao; Peter Yee; Suresh Krishnan; Mirja= K=FChlewind Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. Dear all, We just submitted a new revision of the olsrv2-multipath draft based on the= comments received since the IETF LC, mainly from: Chris: https://www.ietf.org/mail-archive/web/manet/current/msg19426.html Zhen: https://www.ietf.org/mail-archive/web/manet/current/msg19425.html Mirja: https://www.ietf.org/mail-archive/web/manet/current/msg19424.html Peter: https://www.ietf.org/mail-archive/web/manet/current/msg19423.html Alvaro: https://www.ietf.org/mail-archive/web/manet/current/msg19420.html Suresh: https://www.ietf.org/mail-archive/web/manet/current/msg19431.html We appreciate the review and the comments, which certainly help improving t= he quality of the draft a lot. Thanks very much! Further feedback is welcom= e. regards Jiazi On 10 May 2017, at 16:05, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Multipath Extension for the Optimized Link State R= outing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-13.txt Pages : 25 Date : 2017-05-10 Abstract: This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13 https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-13 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/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE63314D5GLKXM0003vGREEN_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Section 7.1 SR_addr origi= nal -> originator.

 <= /p>

Section 8.1, second parag= raph: You can say that because a TC message will be created in every TC_INT= ERVAL, and because SR_TC_INTERVAL >=3D TC_INTERVAL [you want >=3D, even with a  SHOULD for normal behaviour] the normal behavio= ur will ensure a TC message with a SOURCE_ROUTE TLV at least every SR_TC_IN= TERVAL, there’s no need to make it a new requirement.

 <= /p>

Section 8.1, third paragr= aph, should I think more clearly say that it is about routers support sourc= e routing but would not, according to RFC 7181, send TC messages, but now MUST do so. The MUST NOT applied to neighbour addresses = arguably isn’t, as it’s not actually broken for it to do so, bu= t might advertise neighbours for too long. Perhaps a SHOULD NOT? It could a= lso note that if this TC message carries an INTERVAL_TIME TLV (which is optional) it MUST report SR_TC_INTERVAL.<= /o:p>

 <= /p>

Section 8.2 SR_time. We h= aven’t put in place the condition that we never reduce validity times= in analogous places in RFC 7181, so I don’t think that is needed here.

 <= /p>

Last line on page 13 rout= e -> routed.

 <= /p>

Section 9, I think the SR= _TC_INTERVAL and SR_HOLD_TIME constraints are a bit messy, and missing a co= nstraint.

 <= /p>

SR_TC_INTERVAL: MUST be g= reater than or equal to TC_INTERVAL, SHOULD be significantly greater than T= C_INTERVAL, default 10 x TC_INTERVAL.

 <= /p>

SR_HOLD_TIME: MUST be gre= ater than SR_TC_INTERVAL, SHOULD allow for a small number of lost messages,= default is 3 x SR_TC_INTERVAL. (There’s no need to directly relate to TC_INTERVAL here.)

 <= /p>

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: &nb= sp;+44 3300 467500  |  E: chris.dearlove@baesyst= ems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.= baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

 <= /p>

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jiazi Yi
Sent: 10 May 2017 15:16
To: manet
Cc: Dearlove, Christopher (UK); Zhen Cao; Peter Yee; Suresh Krishnan= ; Mirja K=FChlewind
Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-1= 3.txt

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside ou= r organization.

 

Dear all, 

 

We just submitted a new revision of the olsrv2-multi= path draft based on the comments received since the IETF LC, mainly from:

 

 

 

We appreciate the review and the comments, which cer= tainly help improving the quality of the draft a lot. Thanks very much! Fur= ther feedback is welcome. 

 

regards

 

Jiazi

 

On 10 May 2017, at 16:05, internet-drafts@ietf.org wrote:

 


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Mobile Ad-hoc Networks of the IETF.

       Title     &nb= sp;     : Multipath Extension for the Optimized Li= nk State Routing Protocol version 2 (OLSRv2)
       Authors     &= nbsp;   : Jiazi Yi
            &nb= sp;            = Benoit Parrein
       &n= bsp;    Filename       =  : draft-ietf-manet-olsrv2-multipath-13.txt
       &n= bsp;    Pages       &nb= sp;   : 25
       &n= bsp;    Date       &nbs= p;    : 2017-05-10

Abstract:
  This document specifies a multipath extension for the Optimized= Link
  State Routing Protocol version 2 (OLSRv2) to discover multiple<= br>   disjoint paths, so as to improve reliability of the OLSRv2 prot= ocol.
  The interoperability with OLSRv2 is retained.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13
https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-m= ultipath-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multi= path-13


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/

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.or= g/mailman/listinfo/manet

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE63314D5GLKXM0003vGREEN_-- From nobody Wed May 10 08:35:40 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC4B129BF8; Wed, 10 May 2017 08:35:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-manet-olsrv2-multipath@ietf.org, aretana@cisco.com, Stan Ratliff , manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 08:35:39 -0700 Archived-At: Subject: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:35:39 -0000 Warren Kumari has entered the following ballot position for draft-ietf-manet-olsrv2-multipath-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am not a MANET person, and know very little about the Optimized Link State Routing Protocol, however I found this document to be very vague and poorly worded in many places. At some point I simply gave up trying to understand it, but have concerns that it is not sufficiently clear for independent implementations. I almost made these a DISCUSS, but, as I said, I'm not a OLSR person, and so I'm trusting Alvaro to know if it is deployable / implementable Comments: S1.1: "The multi-path extension for OLSRv2 is expected to be revised and improved to the Standard Track," - I'm not sure an extension can be "improved to the Standard Track" - perhaps you mean that the documents will be improved and published as Standards track? Or that once implementations are more stable they will be documented on Standards Track? "Although with existing experience, multiple paths can be obtained even with such partial information, the calculation might be impacted, depending on the MPR selection algorithm used." - I don't understand the "with existing experience", and this sentence is a fragment. I suspect that removing " with existing experience," would make this cleaner, but I don't really understand what you are trying to say... "Different algorithms to obtain multiple paths, other than the default Multi-path Dijkstra algorithm introduced in this specification." - this should have a reference to somewhere in the document. 5.1: "CUTOFF_RATIO The ratio that defines the maximum metric of a path compared to the shortest path kept in the OLSRv2 Routing Set. For example, the metric to a destination is R_metric based on the Routing Set." - I don't understand what the last sentence is trying to say. "CUTOFF_RATIO MUST be greater than or equal to 1. Note that setting the value to 1 means looking for equal length paths, which may not be possible in some networks." -- surely setting it to 2 (or any other number) will also end up looking for paths which might not be possible? E.g: ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌────▶│R1│─▶│R2│─▶│R3├─▶│R4│─────┐ │ └──┘ └──┘ └──┘ └──┘ ▼ ┌───┐ ┌──┐ ┌───┐ │ S │───────────▶│R6│───────────▶│ D │ └───┘ └──┘ └───┘ "SR_HOLD_TIME_MULTIPLIER The multiplier to calculate the minimal time that a SR-OLSRv2 Router Tuple SHOULD be kept in the SR-OLSRv2 Router Set. It is the value of the Message TLV with Type = SOURCE_ROUTE." - this is vague / confusing. I think that you need a reference to Sec 6.1.1. 9. Configuration Parameters "the users of this protocol are also encouraged to explore different parameter setting in various network environments, and provide feedback." -- where? 12. "IANA Considerations This section adds one new Message TLV, allocated as a new Type Extension to an existing Message TLV." -- this section seems to be missing some important information, like which registry this updates Message Type 7 in. Nits: S1.1: "Because the packet drop is normally bursty in a path" -- "Because packet drops on a path are normally bursty"... "Other than general experiences including the protocol specification and interoperability with base OLSRv2 implementations, the experiences in the following aspects are highly appreciated:" s/ experiences including/ experiences, including / (grammar) s/ the experiences / experiences / (grammar) "Although with existing experience, multiple paths can be obtained even with such partial information, the calculation might be impacted, depending on the MPR selection algorithm used." s/Although with existing experience/Although, with existing experience/ (grammar) "In scenarios where the length of the source routing header is critical, the loose source routing can be considered." s/ the loose source / loose source / "for example, the paths with lower metrics (i.e., higher quality) can transfer more datagrams compared to paths with higher metrics." -- nit: many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you might want to clarify (or just say packet) S3: "MP-OLSRv2 is designed for networks with dynamic topology by avoiding single route failure." - this makes it sound like it was *designed* by avoiding single route failure. "in IPv4 networks the interoperability is achieved by using loose source routing header;" - in IPv4 networks interoperability is achieved using loose source routing headers;" (or "by using the loose...") S4: "The reactive operation is local in the router" - "local to the router" S5.1: "All the intermediate routers MUST be included in the source routing header, which makes the number of hops to be kept a variable." -- I don't understand how the "the number of hops to be kept" is "a variable"; this makes it sound like I can set the number of hops to be kept. Perhaps you meant "a variable number of hops" or "the number of hops changes"? From nobody Wed May 10 08:52:39 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2D129C36; Wed, 10 May 2017 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8H1gKyw3-WK; Wed, 10 May 2017 08:52:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B32129498; Wed, 10 May 2017 08:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=514; q=dns/txt; s=iport; t=1494431549; x=1495641149; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=muZx4vvx2UdEpvPJk9a1n1/Ll3VGaLFE7Ge+d2riFEY=; b=HlYmr5eeyz+ZINrJKobg97wemz9Fesi7e36Qru6Is42liHCSURwAnhVc Z7WAiKClsZREPSYzueKJDFSYSonyUjWOHPK2JjGIXhqH4FKdO8WQqFdRW n5xrhPhvospYXcZpKp74oU2wAekcH/2hKE+bkTMJqUuqufq0/0aREyT8M g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQDDNhNZ/5hdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1WBbgeDYooYkTchlXKCD4YkAhqEZj8YAQIBAQEBAQEBayiFFgEEASM?= =?us-ascii?q?RRQULAgEIGgImAgICMBUQAgQBDQWKGQiydIIminQBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdgQuFVIFeKwuCZYRjgw4vgjEBBJZvhxsBkxqBbAGPfpRCAR84gQpwFVg?= =?us-ascii?q?BhGMcGYFKdogMgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208";a="25650624" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 15:52:28 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4AFqSup005551 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2017 15:52:28 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 10 May 2017 10:52:27 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 10 May 2017 10:52:27 -0500 From: "Alvaro Retana (aretana)" To: Warren Kumari , The IESG CC: "draft-ietf-manet-olsrv2-multipath@ietf.org" , Stan Ratliff , "manet-chairs@ietf.org" , "manet@ietf.org" Thread-Topic: Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) Thread-Index: AQHSyaMVZcjkRd37OEiqTDAKQAWdpaHtyFQA Date: Wed, 10 May 2017 15:52:27 +0000 Message-ID: References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> In-Reply-To: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="utf-8" Content-ID: <1B360E9B742EEA498B4631436EBB7E60@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:52:32 -0000 T24gNS8xMC8xNywgMTE6MzUgQU0sICJXYXJyZW4gS3VtYXJpIiA8d2FycmVuQGt1bWFyaS5uZXQ+ IHdyb3RlOg0KDQpXYXJyZW46DQoNCkhpIQ0KDQo+IEkgYWxtb3N0IG1hZGUgdGhlc2UgYSBESVND VVNTLCBidXQsIGFzIEkgc2FpZCwgSSdtIG5vdCBhIE9MU1IgcGVyc29uLCBhbmQNCj4gc28gSSdt IHRydXN0aW5nIEFsdmFybyB0byBrbm93IGlmIGl0IGlzIGRlcGxveWFibGUgLyBpbXBsZW1lbnRh YmxlDQoNClRoZXJlIGFyZSBhbHJlYWR5IDMgb3BlbiBzb3VyY2UgaW1wbGVtZW50YXRpb25zLiDi mLoNCg0KSeKAmWxsIGxldCB0aGUgYXV0aG9ycyBhZGRyZXNzIHRoZSByZXN0IG9mIHRoZSBjb21t ZW50cy4NCg0KVGhhbmtzIQ0KDQpBbHZhcm8uDQoNCg== From nobody Wed May 10 09:11:59 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6302129C5E for ; Wed, 10 May 2017 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5sIIzHg3qrE for ; Wed, 10 May 2017 09:11:50 -0700 (PDT) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9ED129C5F for ; Wed, 10 May 2017 09:11:49 -0700 (PDT) Received: by mail-ua0-f182.google.com with SMTP id e28so520600uah.0 for ; Wed, 10 May 2017 09:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FoatCPwHpoLyQ/AJVSLrUvrd0XI0yKnaQNTBHl2gnE4=; b=ztO82sK5/vETCwjlZVrQRRV8oiVa9SLuGKavzjMjSPyvVc5fsIykJ2WcFs/Cldrp3E 6UTVERgv4nr+GjydO0WVKDZzIXmqBnZeLqF2ClZQqvCR/rMMA+A5VDnCKs9Lu66JL4ZY hddIRjOux8y8AMo50onkgKK21LRrk9V+3ez2oV3i5GSjeuV6TUNx0amtS9Ux2WgMgQT5 fjfS0m/FPhY561VICwatb0NJt2YU1Hkpo4U7abORtKC2KNqTDN/f6KURqkQEf8o+JIVa Ht0pJaUPY+lUIjbriL3tBnPRUf5GXrwHxRuDF4j/yolgX47MXlXgit9sUz37XJmDslTU tuAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FoatCPwHpoLyQ/AJVSLrUvrd0XI0yKnaQNTBHl2gnE4=; b=ndSnXkTBHlVPqrRW0Qwu12O7Ixg2V+x5BInm+KLuKJSqe64zKKv29OnIRgS2XiALBI 29Vbx6by6C2xIzZPFtxhY7vUSsWtQA1Fb6HI4SHmQEWb/qh1Ba9dJJAjGcTpBOXuEOj7 MDPzJOE+zp6THgUXzVQ5jZiZqa0quRYb8e7bkqsJAf93W7e85RmpQ892Scp5PEx1N5Ye kME8Uzo1oadvP4hl85Xbl3DZpY4WYXqSPgknDJDUjOCizDd4cbYCxxeBg8EW1EsP+aFn 1dh6fzbmqYQZItzm8ZCKPyRTZGSHwyEDoX/aAPZisBWMJx/uDYky631rBKPwKy+PF6t8 mBmA== X-Gm-Message-State: AODbwcCQTFqBw2Ca26ZGDfgJX6JJPHLhNKtxMfZQ1fAHJRd5gADGUbC1 s86izCW118SSAF3V6rwj/JhvVNRcYZma X-Received: by 10.31.96.8 with SMTP id u8mr2870648vkb.124.1494432707892; Wed, 10 May 2017 09:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.83 with HTTP; Wed, 10 May 2017 09:11:07 -0700 (PDT) In-Reply-To: References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Wed, 10 May 2017 18:11:07 +0200 Message-ID: To: "Alvaro Retana (aretana)" Cc: The IESG , "draft-ietf-manet-olsrv2-multipath@ietf.org" , Stan Ratliff , "manet-chairs@ietf.org" , "manet@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 16:11:52 -0000 On Wed, May 10, 2017 at 5:52 PM, Alvaro Retana (aretana) wrote: > On 5/10/17, 11:35 AM, "Warren Kumari" wrote: > > Warren: > > Hi! > >> I almost made these a DISCUSS, but, as I said, I'm not a OLSR person, an= d >> so I'm trusting Alvaro to know if it is deployable / implementable > > There are already 3 open source implementations. =E2=98=BA Ah, excellent.... > > I=E2=80=99ll let the authors address the rest of the comments. > > Thanks! > > Alvaro. > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed May 10 16:12:41 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E51200F1 for ; Wed, 10 May 2017 16:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehuhgyYJauPE for ; Wed, 10 May 2017 16:12:36 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5961293DA for ; Wed, 10 May 2017 16:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494457949; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=38469; bh=9nuEedOmq8J/G/ZUlkS6adhIvGzPam1Ct7ik7qvLsFs=; b=jhsQgR6A5h7a3L8UMESYLpCD0eTMxgDSy63XqYstRyXr4JdlehzXrmkg/8AdCab/ E/WrEJxPzZBu1gMB716p+aiHp1fK1v+AM8EtW1AwJp6e+wdw9AHRNVr8Kv16h/Oef/H Y9KxaMsgJWXSh0E7dTYpCO0WV5k3alAKj6C6P0B4= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494457949742691.9254939438686; Wed, 10 May 2017 16:12:29 -0700 (PDT) From: Jiazi Yi Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_25751F13-B30B-4BFF-B417-30BCC1E56040" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 01:12:27 +0200 In-Reply-To: Cc: manet To: "Dearlove, Christopher (UK)" References: <149442511446.26213.1760783097572630645@ietfa.amsl.com> <8019BB63-45FF-4BF2-84AA-EC117B2D0772@jiaziyi.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 23:12:40 -0000 --Apple-Mail=_25751F13-B30B-4BFF-B417-30BCC1E56040 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Chris,=20 > On 10 May 2017, at 17:03, Dearlove, Christopher (UK) = wrote: >=20 > Section 7.1 SR_addr original -> originator. > =20 > Section 8.1, second paragraph: You can say that because a TC message = will be created in every TC_INTERVAL, and because SR_TC_INTERVAL >=3D = TC_INTERVAL [you want >=3D, even with a SHOULD for normal behaviour] = the normal behaviour will ensure a TC message with a SOURCE_ROUTE TLV at = least every SR_TC_INTERVAL, there=E2=80=99s no need to make it a new = requirement. > =20 > Section 8.1, third paragraph, should I think more clearly say that it = is about routers support source routing but would not, according to RFC = 7181, send TC messages, but now MUST do so. The MUST NOT applied to = neighbour addresses arguably isn=E2=80=99t, as it=E2=80=99s not actually = broken for it to do so, but might advertise neighbours for too long. = Perhaps a SHOULD NOT? It could also note that if this TC message carries = an INTERVAL_TIME TLV (which is optional) it MUST report SR_TC_INTERVAL. We plan to update the draft with following text:=20 TC messages are generated according to Section 16.1 of [RFC7181] plus a = single message TLV with Type :=3D SOURCE_ROUTE included.=20 For the routers that do not generate TC messages according to [RFC7181], = at least one TC message MUST be generated by an MP-OLSRv2 Routing = Process during the SR_TC_INTERVAL (Section 5), which MUST be greater = than TC_INTERVAL. Those TC messages MUST NOT carry any advertised = neighbor addresses. This serves for those routers to advertise the = SOURCE_ROUTE TLV so that the other routers can be aware of the = source-route enabled routers so as to be used as destinations of = multipath routing. The validity time associated with the VALIDITY_TIME = TLV in such TC messages equals SR_HOLD_TIME, which MUST be greater than = the SR_TC_INTERVAL. If the TC message carries an optional INTERVAL_TIME = TLV, it MUST have a value encoding the SR_TC_INTERVAL. I prefer keeping the MUST NOT applied to neighbour address =E2=80=94 or = else, it has possibility of setting longer validity time of related = addresses, which is something that we don=E2=80=99t intend to do.=20 Other issues will be fixed in the updated revision also.=20 best Jiazi > =20 > Section 8.2 SR_time. We haven=E2=80=99t put in place the condition = that we never reduce validity times in analogous places in RFC 7181, so = I don=E2=80=99t think that is needed here. > =20 > Last line on page 13 route -> routed. > =20 > Section 9, I think the SR_TC_INTERVAL and SR_HOLD_TIME constraints are = a bit messy, and missing a constraint. > =20 > SR_TC_INTERVAL: MUST be greater than or equal to TC_INTERVAL, SHOULD = be significantly greater than TC_INTERVAL, default 10 x TC_INTERVAL. > =20 > SR_HOLD_TIME: MUST be greater than SR_TC_INTERVAL, SHOULD allow for a = small number of lost messages, default is 3 x SR_TC_INTERVAL. (There=E2=80= =99s no need to directly relate to TC_INTERVAL here.) > =20 > -- >=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > = __________________________________________________________________________= >=20 > T: +44 3300 467500 | E: chris.dearlove@baesystems.com = >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 > =20 > From: manet [mailto:manet-bounces@ietf.org = ] On Behalf Of Jiazi Yi > Sent: 10 May 2017 15:16 > To: manet > Cc: Dearlove, Christopher (UK); Zhen Cao; Peter Yee; Suresh Krishnan; = Mirja K=C3=BChlewind > Subject: Re: [manet] I-D Action: = draft-ietf-manet-olsrv2-multipath-13.txt > =20 > =20 > *** WARNING *** > This message originates from outside our organisation, either from an = external partner or the internet. > Consider carefully whether you should click on any links, open any = attachments or reply. > For information regarding Red Flags that you can look out for in = emails you receive, click here = . > If you feel the email is suspicious, please follow this process = . >=20 > *** WARNING *** > EXTERNAL EMAIL -- This message originates from outside our = organization. > =20 > Dear all,=20 > =20 > We just submitted a new revision of the olsrv2-multipath draft based = on the comments received since the IETF LC, mainly from: > =20 > Chris: = https://www.ietf.org/mail-archive/web/manet/current/msg19426.html = > Zhen: = https://www.ietf.org/mail-archive/web/manet/current/msg19425.html = > Mirja: = https://www.ietf.org/mail-archive/web/manet/current/msg19424.html = > Peter: = https://www.ietf.org/mail-archive/web/manet/current/msg19423.html = > Alvaro: = https://www.ietf.org/mail-archive/web/manet/current/msg19420.html = > Suresh: = https://www.ietf.org/mail-archive/web/manet/current/msg19431.html = > =20 > =20 > We appreciate the review and the comments, which certainly help = improving the quality of the draft a lot. Thanks very much! Further = feedback is welcome.=20 > =20 > regards > =20 > Jiazi > =20 > On 10 May 2017, at 16:05, internet-drafts@ietf.org = wrote: > =20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Mobile Ad-hoc Networks of the IETF. >=20 > Title : Multipath Extension for the Optimized Link = State Routing Protocol version 2 (OLSRv2) > Authors : Jiazi Yi > Benoit Parrein > Filename : draft-ietf-manet-olsrv2-multipath-13.txt > Pages : 25 > Date : 2017-05-10 >=20 > Abstract: > This document specifies a multipath extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > The interoperability with OLSRv2 is retained. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-13 = > = https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-13= = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-13= = = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = > =20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 --Apple-Mail=_25751F13-B30B-4BFF-B417-30BCC1E56040 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Chris, 



On = 10 May 2017, at 17:03, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Section 7.1 SR_addr = original -> originator.
 
Section 8.1, second = paragraph: You can say that because a TC message will be created in = every TC_INTERVAL, and because SR_TC_INTERVAL >=3D TC_INTERVAL [you = want >=3D, even with a  SHOULD for normal behaviour] the normal = behaviour will ensure a TC message with a SOURCE_ROUTE TLV at least = every SR_TC_INTERVAL, there=E2=80=99s no need to make it a new = requirement.
 
Section 8.1, third = paragraph, should I think more clearly say that it is about routers = support source routing but would not, according to RFC 7181, send TC = messages, but now MUST do so. The MUST NOT applied to neighbour = addresses arguably isn=E2=80=99t, as it=E2=80=99s not actually broken = for it to do so, but might advertise neighbours for too long. Perhaps a = SHOULD NOT? It could also note that if this TC message carries an = INTERVAL_TIME TLV (which is optional) it MUST report = SR_TC_INTERVAL.

We plan to update the draft with following = text: 

TC messages are generated according = to Section 16.1 of [RFC7181] plus a single message TLV with = Type :=3D SOURCE_ROUTE included. 

For = the routers that do not generate TC messages according = to [RFC7181], at least one TC message MUST be generated by an = MP-OLSRv2 Routing Process during the SR_TC_INTERVAL (Section 5), which = MUST be greater than TC_INTERVAL. Those TC messages MUST NOT carry = any advertised neighbor addresses. This serves for those routers to = advertise the SOURCE_ROUTE TLV so that the other routers can be aware of = the source-route enabled routers so as to be used as destinations = of multipath routing. The validity time associated with = the VALIDITY_TIME TLV in such TC messages equals SR_HOLD_TIME, = which MUST be greater than the SR_TC_INTERVAL. If the TC message = carries an optional INTERVAL_TIME TLV, it MUST have a value encoding = the SR_TC_INTERVAL.

I prefer keeping the MUST NOT applied to neighbour = address =E2=80=94 or else, it has possibility of setting longer validity = time of related addresses, which is something that we don=E2=80=99t = intend to do. 

Other issues = will be fixed in the updated revision also. 

best

Jiazi


 
Section 8.2 SR_time. We = haven=E2=80=99t put in place the condition that we never reduce validity = times in analogous places in RFC 7181, so I don=E2=80=99t think that is = needed here.
 
Last line on page 13 = route -> routed.
 
Section 9, I think the = SR_TC_INTERVAL and SR_HOLD_TIME constraints are a bit messy, and missing = a constraint.
 
SR_TC_INTERVAL: MUST be = greater than or equal to TC_INTERVAL, SHOULD be significantly greater = than TC_INTERVAL, default 10 x TC_INTERVAL.
 
SR_HOLD_TIME: MUST be = greater than SR_TC_INTERVAL, SHOULD allow for a small number of lost = messages, default is 3 x SR_TC_INTERVAL. (There=E2=80=99s no need to = directly relate to TC_INTERVAL here.)
 

--

Christopher Dearlove
Senior Principal = Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________________________________________= ___________

T:  +44 = 3300 467500  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, = Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research = Park, Guildford, Surrey, GU2 7YP

 
From: manet [mailto:manet-bounces@ietf.org] On Behalf = Of Jiazi Yi
Sent: 10 May 2017 15:16
To: manet
Cc: Dearlove, Christopher (UK); = Zhen Cao; Peter Yee; Suresh Krishnan; Mirja K=C3=BChlewind
Subject: Re: [manet] I-D Action: = draft-ietf-manet-olsrv2-multipath-13.txt
 
 
*** WARNING ***

This message originates from outside our = organisation, either from an external partner or the = internet.
Consider carefully whether you should click on = any links, open any attachments or reply.
For = information regarding Red = Flags that you = can look out for in emails you receive, click here.
If = you feel the email is suspicious, please follow this = process.

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our = organization.
 
Dear all, 
 
We just submitted a new revision of the = olsrv2-multipath draft based on the comments received since the IETF LC, = mainly from:
 
Chris: https://www.ietf.org/mail-archive/web/manet/current/msg19426.ht= ml
Zhen: https://www.ietf.org/mail-archive/web/manet/current/msg19425.ht= ml
Mirja: https://www.ietf.org/mail-archive/web/manet/current/msg19424.ht= ml
Peter: https://www.ietf.org/mail-archive/web/manet/current/msg19423.ht= ml
Alvaro: https://www.ietf.org/mail-archive/web/manet/current/msg19420.ht= ml
Suresh: https://www.ietf.org/mail-archive/web/manet/current/msg19431.ht= ml
 
 
We appreciate the review and the comments, which = certainly help improving the quality of the draft a lot. Thanks very = much! Further feedback is welcome. 
 
regards
 
Jiazi
 
On = 10 May 2017, at 16:05, internet-drafts@ietf.org wrote:
 

A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This= draft is a work item of the Mobile Ad-hoc Networks of the IETF.

       Title =           : Multipath = Extension for the Optimized Link State Routing Protocol version 2 = (OLSRv2)
       Authors =         : Jiazi Yi
          &nb= sp;            = ;  Benoit Parrein
        &= nbsp;   Filename =        : = draft-ietf-manet-olsrv2-multipath-13.txt
        &= nbsp;   Pages =           : 25
        &= nbsp;   Date =            : = 2017-05-10

Abstract:
  This document specifies a multipath extension for = the Optimized Link
  State Routing Protocol = version 2 (OLSRv2) to discover multiple
  disjoint= paths, so as to improve reliability of the OLSRv2 protocol.
  The interoperability with OLSRv2 is retained.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multip= ath/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-1= 3
https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-m= ultipath-13

A diff from the previous = version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mul= tipath-13


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/

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

***************************************************************= *****
This email and any attachments are confidential to = the intended
recipient and may also be privileged. If you = are not the intended
recipient please delete it from your = system and notify the sender.
You should not copy it or = use it for any purpose nor disclose or
distribute its = contents to any other person.
***************************************************************= *****


= --Apple-Mail=_25751F13-B30B-4BFF-B417-30BCC1E56040-- From nobody Wed May 10 23:13:36 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 354C812EB64; Wed, 10 May 2017 23:13:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-manet-olsrv2-multipath@ietf.org, aretana@cisco.com, Stan Ratliff , manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149448320721.16690.6113367666672173681.idtracker@ietfa.amsl.com> Date: Wed, 10 May 2017 23:13:27 -0700 Archived-At: Subject: [manet] Adam Roach's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 06:13:27 -0000 Adam Roach has entered the following ballot position for draft-ietf-manet-olsrv2-multipath-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I reviewed the -12 version of this document, and had a comment I was going to make about dropping packets when no contiguous path of source-routing capable routers existed between the endpoints; but when I went to quote the offending text, discovered that it has been fixed in the ink-is-still-wet -13 version of the document, dropped one day before the telechat. To highlight for anyone else who has similarly reviewed the -12 version: the only other non-editorial change I find is that avoiding fragmentation has been demoted from normative to non-normative (see the last two paragraphs of section 8.4). My intuition is that fragmentation is sufficiently disruptive that normative language is called for here, but I don't feel strongly about it. From nobody Thu May 11 01:14:14 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA810127BA3; Thu, 11 May 2017 01:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b16tgciFlcA3; Thu, 11 May 2017 01:14:10 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B8F120454; Thu, 11 May 2017 01:14:10 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F283618013D1; Thu, 11 May 2017 10:14:07 +0200 (CEST) From: Loa Andersson To: "" Cc: "rtg-dir@ietf.org" , draft-ietf-manet-olsrv2-multipath@ietf.org, manet@ietf.org Message-ID: <1ea04d3a-2446-dcaa-e5b6-21797a3caa57@pi.nu> Date: Thu, 11 May 2017 10:14:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [manet] RtgDir review of draft-ietf-manet-olsrv2-multipath-12.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 08:14:13 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-manet-olsrv2-multipath-12.txt Reviewer: Loa Andersson Review Date: 2017-05-11 IETF LC End Date: 2015-05-11 (?) Intended Status: Experimental Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: The draft is well written and readable also for someone that does not read manet-draft that often. Major Issues: "No major issues found. Minor Issues: "No minor issues found." Nits: I've looked at the the GenArt review by Peter Yee and the Intdir review by Zhen Cao and largely agree with their comments. In addition: The nits tool picks on something that looks like references on line 469 ( [1] and [2] ) but is not. Don't think you'll need to fix that, the RFC Editor will fix if necessary. I'd like to have the Abstract fleshed out a bit, some more context given. If you are new to the area and the draft it is very hard to find the expected useful info in the abstract. You use "TC message" already in section 4, but TC (Traffic Control) is not expanded until section 6, should be done the first time it is used. The abbreviation "SR" is used (often as part of parameter names), but never really expanded, though one can find the expansion kind of explained at some places. Could be made clearer. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu May 11 01:48:32 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0C512EB81 for ; Thu, 11 May 2017 01:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzMyDXSH7exX for ; Thu, 11 May 2017 01:48:26 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E2112EB7F for ; Thu, 11 May 2017 01:48:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,323,1491260400"; d="scan'208,217";a="69141" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 11 May 2017 09:48:21 +0100 X-IronPort-AV: E=Sophos;i="5.38,323,1491260400"; d="scan'208,217";a="170836013" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 11 May 2017 09:47:58 +0100 Received: from GLKXM0003V.GREENLNK.net ([169.254.4.172]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Thu, 11 May 2017 09:47:58 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi Yi CC: manet Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt Thread-Index: AQHSyZaBRhUgiyHbekGG9bOYeH0cTqHti90AgAAXDRCAAH7tgIAAsPBA Date: Thu, 11 May 2017 08:47:58 +0000 Message-ID: References: <149442511446.26213.1760783097572630645@ietfa.amsl.com> <8019BB63-45FF-4BF2-84AA-EC117B2D0772@jiaziyi.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE6334074GLKXM0003vGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-13.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 08:48:31 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE6334074GLKXM0003vGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 cy9TUl9UQ19JTlRFUlZBTCAoU2VjdGlvbiA1KSwgd2hpY2ggTVVTVCBiZSBncmVhdGVyIHRoYW4g VENfSU5URVJWQUwvU1JfVENfSU5URVJWQUwgKFNlY3Rpb24gNSksIHdoaWNoIE1VU1QgYmUgZ3Jl YXRlciB0aGFuIG9yIGVxdWFsIHRvIFRDX0lOVEVSVkFMLw0KDQpPdGhlcndpc2UgbG9va3MgZ29v ZCB0byBtZS4gQWxzbyBuZWVkIHRvIGFkZHJlc3MgU2VjdGlvbiA5IHRvIG1hdGNoIG9mIGNvdXJz ZS4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVy DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNClQ6ICArNDQgMzMwMCA0Njc1MDAgIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCg0KQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJr LCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVt cy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5v OiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWls ZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBKaWF6aSBZaSBbbWFpbHRvOmlldGZAamlh eml5aS5jb21dDQpTZW50OiAxMSBNYXkgMjAxNyAwMDoxMg0KVG86IERlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspDQpDYzogbWFuZXQNClN1YmplY3Q6IFJlOiBbbWFuZXRdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMy50eHQNCg0KDQoqKiogV0FSTklORyAq KioNClRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9u LCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNp ZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVu IGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVk IEZsYWdzIHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBj bGljayBoZXJlPGh0dHA6Ly93cy1zaXRlcy5lbnQuYmFlc3lzdGVtcy5jb20vc2l0ZXMvSE9TRUNT dGRzTGlicmFyeS9TdGFuZGFyZHNMaWJyYXJ5L0V2ZXJ5b25lL1JlZCUyMEZsYWdzLnBkZj4uDQpJ ZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHBy b2Nlc3M8aHR0cDovL3dzLXNpdGVzLmVudC5iYWVzeXN0ZW1zLmNvbS9zaXRlcy9IT1NFQ1N0ZHNM aWJyYXJ5L1N0YW5kYXJkc0xpYnJhcnkvRXZlcnlvbmUvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNp b3VzJTIwRW1haWxzLnBkZj4uDQpEZWFyIENocmlzLA0KDQoNCg0KT24gMTAgTWF5IDIwMTcsIGF0 IDE3OjAzLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQoN ClNlY3Rpb24gNy4xIFNSX2FkZHIgb3JpZ2luYWwgLT4gb3JpZ2luYXRvci4NCg0KU2VjdGlvbiA4 LjEsIHNlY29uZCBwYXJhZ3JhcGg6IFlvdSBjYW4gc2F5IHRoYXQgYmVjYXVzZSBhIFRDIG1lc3Nh Z2Ugd2lsbCBiZSBjcmVhdGVkIGluIGV2ZXJ5IFRDX0lOVEVSVkFMLCBhbmQgYmVjYXVzZSBTUl9U Q19JTlRFUlZBTCA+PSBUQ19JTlRFUlZBTCBbeW91IHdhbnQgPj0sIGV2ZW4gd2l0aCBhICBTSE9V TEQgZm9yIG5vcm1hbCBiZWhhdmlvdXJdIHRoZSBub3JtYWwgYmVoYXZpb3VyIHdpbGwgZW5zdXJl IGEgVEMgbWVzc2FnZSB3aXRoIGEgU09VUkNFX1JPVVRFIFRMViBhdCBsZWFzdCBldmVyeSBTUl9U Q19JTlRFUlZBTCwgdGhlcmXigJlzIG5vIG5lZWQgdG8gbWFrZSBpdCBhIG5ldyByZXF1aXJlbWVu dC4NCg0KU2VjdGlvbiA4LjEsIHRoaXJkIHBhcmFncmFwaCwgc2hvdWxkIEkgdGhpbmsgbW9yZSBj bGVhcmx5IHNheSB0aGF0IGl0IGlzIGFib3V0IHJvdXRlcnMgc3VwcG9ydCBzb3VyY2Ugcm91dGlu ZyBidXQgd291bGQgbm90LCBhY2NvcmRpbmcgdG8gUkZDIDcxODEsIHNlbmQgVEMgbWVzc2FnZXMs IGJ1dCBub3cgTVVTVCBkbyBzby4gVGhlIE1VU1QgTk9UIGFwcGxpZWQgdG8gbmVpZ2hib3VyIGFk ZHJlc3NlcyBhcmd1YWJseSBpc27igJl0LCBhcyBpdOKAmXMgbm90IGFjdHVhbGx5IGJyb2tlbiBm b3IgaXQgdG8gZG8gc28sIGJ1dCBtaWdodCBhZHZlcnRpc2UgbmVpZ2hib3VycyBmb3IgdG9vIGxv bmcuIFBlcmhhcHMgYSBTSE9VTEQgTk9UPyBJdCBjb3VsZCBhbHNvIG5vdGUgdGhhdCBpZiB0aGlz IFRDIG1lc3NhZ2UgY2FycmllcyBhbiBJTlRFUlZBTF9USU1FIFRMViAod2hpY2ggaXMgb3B0aW9u YWwpIGl0IE1VU1QgcmVwb3J0IFNSX1RDX0lOVEVSVkFMLg0KDQpXZSBwbGFuIHRvIHVwZGF0ZSB0 aGUgZHJhZnQgd2l0aCBmb2xsb3dpbmcgdGV4dDoNCg0KVEMgbWVzc2FnZXMgYXJlIGdlbmVyYXRl ZCBhY2NvcmRpbmcgdG8gU2VjdGlvbiAxNi4xIG9mIFtSRkM3MTgxXSBwbHVzIGEgc2luZ2xlIG1l c3NhZ2UgVExWIHdpdGggVHlwZSA6PSBTT1VSQ0VfUk9VVEUgaW5jbHVkZWQuDQoNCkZvciB0aGUg cm91dGVycyB0aGF0IGRvIG5vdCBnZW5lcmF0ZSBUQyBtZXNzYWdlcyBhY2NvcmRpbmcgdG8gW1JG QzcxODFdLCBhdCBsZWFzdCBvbmUgVEMgbWVzc2FnZSBNVVNUIGJlIGdlbmVyYXRlZCBieSBhbiBN UC1PTFNSdjIgUm91dGluZyBQcm9jZXNzIGR1cmluZyB0aGUgU1JfVENfSU5URVJWQUwgKFNlY3Rp b24gNSksIHdoaWNoIE1VU1QgYmUgZ3JlYXRlciB0aGFuIFRDX0lOVEVSVkFMLiBUaG9zZSBUQyBt ZXNzYWdlcyBNVVNUIE5PVCBjYXJyeSBhbnkgYWR2ZXJ0aXNlZCBuZWlnaGJvciBhZGRyZXNzZXMu IFRoaXMgc2VydmVzIGZvciB0aG9zZSByb3V0ZXJzIHRvIGFkdmVydGlzZSB0aGUgU09VUkNFX1JP VVRFIFRMViBzbyB0aGF0IHRoZSBvdGhlciByb3V0ZXJzIGNhbiBiZSBhd2FyZSBvZiB0aGUgc291 cmNlLXJvdXRlIGVuYWJsZWQgcm91dGVycyBzbyBhcyB0byBiZSB1c2VkIGFzIGRlc3RpbmF0aW9u cyBvZiBtdWx0aXBhdGggcm91dGluZy4gVGhlIHZhbGlkaXR5IHRpbWUgYXNzb2NpYXRlZCB3aXRo IHRoZSBWQUxJRElUWV9USU1FIFRMViBpbiBzdWNoIFRDIG1lc3NhZ2VzIGVxdWFscyBTUl9IT0xE X1RJTUUsIHdoaWNoIE1VU1QgYmUgZ3JlYXRlciB0aGFuIHRoZSBTUl9UQ19JTlRFUlZBTC4gSWYg dGhlIFRDIG1lc3NhZ2UgY2FycmllcyBhbiBvcHRpb25hbCBJTlRFUlZBTF9USU1FIFRMViwgaXQg TVVTVCBoYXZlIGEgdmFsdWUgZW5jb2RpbmcgdGhlIFNSX1RDX0lOVEVSVkFMLg0KDQpJIHByZWZl ciBrZWVwaW5nIHRoZSBNVVNUIE5PVCBhcHBsaWVkIHRvIG5laWdoYm91ciBhZGRyZXNzIOKAlCBv ciBlbHNlLCBpdCBoYXMgcG9zc2liaWxpdHkgb2Ygc2V0dGluZyBsb25nZXIgdmFsaWRpdHkgdGlt ZSBvZiByZWxhdGVkIGFkZHJlc3Nlcywgd2hpY2ggaXMgc29tZXRoaW5nIHRoYXQgd2UgZG9u4oCZ dCBpbnRlbmQgdG8gZG8uDQoNCk90aGVyIGlzc3VlcyB3aWxsIGJlIGZpeGVkIGluIHRoZSB1cGRh dGVkIHJldmlzaW9uIGFsc28uDQoNCmJlc3QNCg0KSmlhemkNCg0KDQoNCg0KU2VjdGlvbiA4LjIg U1JfdGltZS4gV2UgaGF2ZW7igJl0IHB1dCBpbiBwbGFjZSB0aGUgY29uZGl0aW9uIHRoYXQgd2Ug bmV2ZXIgcmVkdWNlIHZhbGlkaXR5IHRpbWVzIGluIGFuYWxvZ291cyBwbGFjZXMgaW4gUkZDIDcx ODEsIHNvIEkgZG9u4oCZdCB0aGluayB0aGF0IGlzIG5lZWRlZCBoZXJlLg0KDQpMYXN0IGxpbmUg b24gcGFnZSAxMyByb3V0ZSAtPiByb3V0ZWQuDQoNClNlY3Rpb24gOSwgSSB0aGluayB0aGUgU1Jf VENfSU5URVJWQUwgYW5kIFNSX0hPTERfVElNRSBjb25zdHJhaW50cyBhcmUgYSBiaXQgbWVzc3ks IGFuZCBtaXNzaW5nIGEgY29uc3RyYWludC4NCg0KU1JfVENfSU5URVJWQUw6IE1VU1QgYmUgZ3Jl YXRlciB0aGFuIG9yIGVxdWFsIHRvIFRDX0lOVEVSVkFMLCBTSE9VTEQgYmUgc2lnbmlmaWNhbnRs eSBncmVhdGVyIHRoYW4gVENfSU5URVJWQUwsIGRlZmF1bHQgMTAgeCBUQ19JTlRFUlZBTC4NCg0K U1JfSE9MRF9USU1FOiBNVVNUIGJlIGdyZWF0ZXIgdGhhbiBTUl9UQ19JTlRFUlZBTCwgU0hPVUxE IGFsbG93IGZvciBhIHNtYWxsIG51bWJlciBvZiBsb3N0IG1lc3NhZ2VzLCBkZWZhdWx0IGlzIDMg eCBTUl9UQ19JTlRFUlZBTC4gKFRoZXJl4oCZcyBubyBuZWVkIHRvIGRpcmVjdGx5IHJlbGF0ZSB0 byBUQ19JTlRFUlZBTCBoZXJlLikNCg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3Ig UHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJv cmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgMzMwMCA0Njc1MDAgIHwgIEU6 IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2Zv cmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4 SE4uDQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4N CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4g RW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBS ZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQpGcm9tOiBtYW5ldCBb bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKaWF6aSBZaQ0KU2Vu dDogMTAgTWF5IDIwMTcgMTU6MTYNClRvOiBtYW5ldA0KQ2M6IERlYXJsb3ZlLCBDaHJpc3RvcGhl ciAoVUspOyBaaGVuIENhbzsgUGV0ZXIgWWVlOyBTdXJlc2ggS3Jpc2huYW47IE1pcmphIEvDvGhs ZXdpbmQNClN1YmplY3Q6IFJlOiBbbWFuZXRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQt b2xzcnYyLW11bHRpcGF0aC0xMy50eHQNCg0KDQoqKiogV0FSTklORyAqKioNClRoaXMgbWVzc2Fn ZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBh biBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3 aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50 cyBvciByZXBseS4NCkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgUmVkIEZsYWdzIHRoYXQgeW91 IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayBoZXJlPGh0dHA6 Ly93cy1zaXRlcy5lbnQuYmFlc3lzdGVtcy5jb20vc2l0ZXMvSE9TRUNTdGRzTGlicmFyeS9TdGFu ZGFyZHNMaWJyYXJ5L0V2ZXJ5b25lL1JlZCUyMEZsYWdzLnBkZj4uDQpJZiB5b3UgZmVlbCB0aGUg ZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdyB0aGlzIHByb2Nlc3M8aHR0cDovL3dz LXNpdGVzLmVudC5iYWVzeXN0ZW1zLmNvbS9zaXRlcy9IT1NFQ1N0ZHNMaWJyYXJ5L1N0YW5kYXJk c0xpYnJhcnkvRXZlcnlvbmUvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBk Zj4uDQoqKiogV0FSTklORyAqKioNCkVYVEVSTkFMIEVNQUlMIC0tIFRoaXMgbWVzc2FnZSBvcmln aW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pemF0aW9uLg0KDQpEZWFyIGFsbCwNCg0KV2Ug anVzdCBzdWJtaXR0ZWQgYSBuZXcgcmV2aXNpb24gb2YgdGhlIG9sc3J2Mi1tdWx0aXBhdGggZHJh ZnQgYmFzZWQgb24gdGhlIGNvbW1lbnRzIHJlY2VpdmVkIHNpbmNlIHRoZSBJRVRGIExDLCBtYWlu bHkgZnJvbToNCg0KQ2hyaXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bWFuZXQvY3VycmVudC9tc2cxOTQyNi5odG1sDQpaaGVuOiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTk0MjUuaHRtbA0KTWlyamE6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxOTQyNC5o dG1sDQpQZXRlcjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9j dXJyZW50L21zZzE5NDIzLmh0bWwNCkFsdmFybzogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE5NDIwLmh0bWwNClN1cmVzaDogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE5NDMxLmh0bWwN Cg0KDQpXZSBhcHByZWNpYXRlIHRoZSByZXZpZXcgYW5kIHRoZSBjb21tZW50cywgd2hpY2ggY2Vy dGFpbmx5IGhlbHAgaW1wcm92aW5nIHRoZSBxdWFsaXR5IG9mIHRoZSBkcmFmdCBhIGxvdC4gVGhh bmtzIHZlcnkgbXVjaCEgRnVydGhlciBmZWVkYmFjayBpcyB3ZWxjb21lLg0KDQpyZWdhcmRzDQoN CkppYXppDQoNCk9uIDEwIE1heSAyMDE3LCBhdCAxNjowNSwgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE1vYmlsZSBB ZC1ob2MgTmV0d29ya3Mgb2YgdGhlIElFVEYuDQoNCiAgICAgICBUaXRsZSAgICAgICAgICAgOiBN dWx0aXBhdGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsgU3RhdGUgUm91dGluZyBQ cm90b2NvbCB2ZXJzaW9uIDIgKE9MU1J2MikNCiAgICAgICBBdXRob3JzICAgICAgICAgOiBKaWF6 aSBZaQ0KICAgICAgICAgICAgICAgICAgICAgICAgIEJlbm9pdCBQYXJyZWluDQogICAgICAgICAg ICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTMu dHh0DQogICAgICAgICAgICBQYWdlcyAgICAgICAgICAgOiAyNQ0KICAgICAgICAgICAgRGF0ZSAg ICAgICAgICAgIDogMjAxNy0wNS0xMA0KDQpBYnN0cmFjdDoNCiAgVGhpcyBkb2N1bWVudCBzcGVj aWZpZXMgYSBtdWx0aXBhdGggZXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsNCiAgU3Rh dGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDIgKE9MU1J2MikgdG8gZGlzY292ZXIgbXVsdGlw bGUNCiAgZGlzam9pbnQgcGF0aHMsIHNvIGFzIHRvIGltcHJvdmUgcmVsaWFiaWxpdHkgb2YgdGhl IE9MU1J2MiBwcm90b2NvbC4NCiAgVGhlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBPTFNSdjIgaXMg cmV0YWluZWQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg ZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1h bmV0LW9sc3J2Mi1tdWx0aXBhdGgvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25z IGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1h bmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTMNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEzDQoNCkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0aXBhdGgtMTMNCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4u DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1h bmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50 IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQN CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0 aGUgc2VuZGVyLg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJw b3NlIG5vciBkaXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbi4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQoNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE6334074GLKXM0003vGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+cy88L3NwYW4+U1JfVENfSU5URVJW QUwgKFNlY3Rpb24gNSksIHdoaWNoIE1VU1QgYmUgZ3JlYXRlciZuYnNwO3RoYW4gVENfSU5URVJW QUwvU1JfVENfSU5URVJWQUwgKFNlY3Rpb24gNSksIHdoaWNoIE1VU1QgYmUgZ3JlYXRlciZuYnNw O3RoYW4gb3IgZXF1YWwgdG8gVENfSU5URVJWQUwvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk90 aGVyd2lzZSBsb29rcyBnb29kIHRvIG1lLiBBbHNvIG5lZWQgdG8gYWRkcmVzcyBTZWN0aW9uIDkg dG8gbWF0Y2ggb2YgY291cnNlLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0K PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDA3RTdFIj5DaHJpc3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5l ZXI8YnI+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMYWJvcmF0b3JpZXM8YnI+ DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojN0Q3RDdEIj46ICZuYnNwOyYjNDM7NDQgMzMwMCA0Njc1MDAgJm5ic3A7fCAmbmJzcDs8Yj5F Og0KPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBD aGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3Nl eCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxz cGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGln ZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZhbXA7IFdhbGVzIE5vOiAw MTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMz QThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3Jk LCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gSmlhemkgWWkgW21haWx0bzppZXRmQGppYXppeWkuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IDExIE1heSAyMDE3IDAwOjEyPGJyPg0KPGI+VG86PC9iPiBEZWFybG92ZSwg Q2hyaXN0b3BoZXIgKFVLKTxicj4NCjxiPkNjOjwvYj4gbWFuZXQ8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFttYW5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlw YXRoLTEzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpz b2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFj a2dyb3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMz OTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlv biwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFu PjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8 ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sg b24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48 YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9l bT48L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpy ZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxz IHlvdSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly93cy1zaXRlcy5lbnQuYmFlc3lz dGVtcy5jb20vc2l0ZXMvSE9TRUNTdGRzTGlicmFyeS9TdGFuZGFyZHNMaWJyYXJ5L0V2ZXJ5b25l L1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZl ZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6 Ly93cy1zaXRlcy5lbnQuYmFlc3lzdGVtcy5jb20vc2l0ZXMvSE9TRUNTdGRzTGlicmFyeS9TdGFu ZGFyZHNMaWJyYXJ5L0V2ZXJ5b25lL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWls cy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIENocmlzLCZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gMTAgTWF5IDIwMTcsIGF0IDE3OjAzLCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFy bG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNlY3Rpb24gNy4xIFNSX2FkZHIgb3JpZ2luYWwgLSZndDsgb3JpZ2luYXRvci48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gOC4xLCBzZWNv bmQgcGFyYWdyYXBoOiBZb3UgY2FuIHNheSB0aGF0IGJlY2F1c2UgYSBUQyBtZXNzYWdlIHdpbGwg YmUgY3JlYXRlZCBpbiBldmVyeSBUQ19JTlRFUlZBTCwgYW5kIGJlY2F1c2UgU1JfVENfSU5URVJW QUwgJmd0Oz0gVENfSU5URVJWQUwgW3lvdSB3YW50DQogJmd0Oz0sIGV2ZW4gd2l0aCBhICZuYnNw O1NIT1VMRCBmb3Igbm9ybWFsIGJlaGF2aW91cl0gdGhlIG5vcm1hbCBiZWhhdmlvdXIgd2lsbCBl bnN1cmUgYSBUQyBtZXNzYWdlIHdpdGggYSBTT1VSQ0VfUk9VVEUgVExWIGF0IGxlYXN0IGV2ZXJ5 IFNSX1RDX0lOVEVSVkFMLCB0aGVyZeKAmXMgbm8gbmVlZCB0byBtYWtlIGl0IGEgbmV3IHJlcXVp cmVtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiA4 LjEsIHRoaXJkIHBhcmFncmFwaCwgc2hvdWxkIEkgdGhpbmsgbW9yZSBjbGVhcmx5IHNheSB0aGF0 IGl0IGlzIGFib3V0IHJvdXRlcnMgc3VwcG9ydCBzb3VyY2Ugcm91dGluZyBidXQgd291bGQgbm90 LCBhY2NvcmRpbmcgdG8gUkZDIDcxODEsIHNlbmQgVEMNCiBtZXNzYWdlcywgYnV0IG5vdyBNVVNU IGRvIHNvLiBUaGUgTVVTVCBOT1QgYXBwbGllZCB0byBuZWlnaGJvdXIgYWRkcmVzc2VzIGFyZ3Vh Ymx5IGlzbuKAmXQsIGFzIGl04oCZcyBub3QgYWN0dWFsbHkgYnJva2VuIGZvciBpdCB0byBkbyBz bywgYnV0IG1pZ2h0IGFkdmVydGlzZSBuZWlnaGJvdXJzIGZvciB0b28gbG9uZy4gUGVyaGFwcyBh IFNIT1VMRCBOT1Q/IEl0IGNvdWxkIGFsc28gbm90ZSB0aGF0IGlmIHRoaXMgVEMgbWVzc2FnZSBj YXJyaWVzIGFuDQogSU5URVJWQUxfVElNRSBUTFYgKHdoaWNoIGlzIG9wdGlvbmFsKSBpdCBNVVNU IHJlcG9ydCBTUl9UQ19JTlRFUlZBTC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgcGxh biB0byB1cGRhdGUgdGhlIGRyYWZ0IHdpdGggZm9sbG93aW5nIHRleHQ6Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzAuMHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48aT5UQyBtZXNzYWdlcyBhcmUgZ2VuZXJhdGVkIGFjY29yZGluZyB0byBTZWN0aW9uIDE2 LjEgb2YmbmJzcDtbUkZDNzE4MV0mbmJzcDtwbHVzIGEgc2luZ2xlIG1lc3NhZ2UgVExWIHdpdGgg VHlwZSA6PSZuYnNwO1NPVVJDRV9ST1VURSBpbmNsdWRlZC4mbmJzcDs8L2k+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxpPkZvciB0aGUgcm91dGVycyB0aGF0IGRvIG5vdCBnZW5lcmF0ZSBU QyBtZXNzYWdlcyBhY2NvcmRpbmcgdG8mbmJzcDtbUkZDNzE4MV0sIGF0IGxlYXN0IG9uZSBUQyBt ZXNzYWdlIE1VU1QgYmUmbmJzcDtnZW5lcmF0ZWQgYnkgYW4gTVAtT0xTUnYyIFJvdXRpbmcgUHJv Y2VzcyBkdXJpbmcgdGhlIFNSX1RDX0lOVEVSVkFMIChTZWN0aW9uIDUpLCB3aGljaCBNVVNUIGJl IGdyZWF0ZXImbmJzcDt0aGFuIFRDX0lOVEVSVkFMLiBUaG9zZSBUQw0KIG1lc3NhZ2VzIE1VU1Qg Tk9UIGNhcnJ5IGFueSBhZHZlcnRpc2VkIG5laWdoYm9yIGFkZHJlc3Nlcy4gVGhpcyBzZXJ2ZXMg Zm9yJm5ic3A7dGhvc2Ugcm91dGVycyB0byBhZHZlcnRpc2UgdGhlIFNPVVJDRV9ST1VURSBUTFYg c28gdGhhdCB0aGUgb3RoZXIgcm91dGVycyBjYW4gYmUgYXdhcmUgb2YgdGhlIHNvdXJjZS1yb3V0 ZSZuYnNwO2VuYWJsZWQgcm91dGVycyBzbyBhcyB0byBiZSB1c2VkIGFzIGRlc3RpbmF0aW9ucyBv ZiBtdWx0aXBhdGggcm91dGluZy4gVGhlDQogdmFsaWRpdHkgdGltZSBhc3NvY2lhdGVkIHdpdGgg dGhlJm5ic3A7VkFMSURJVFlfVElNRSBUTFYgaW4gc3VjaCBUQyBtZXNzYWdlcyBlcXVhbHMgU1Jf SE9MRF9USU1FLCB3aGljaCBNVVNUIGJlIGdyZWF0ZXIgdGhhbiB0aGUmbmJzcDtTUl9UQ19JTlRF UlZBTC4gSWYgdGhlIFRDIG1lc3NhZ2UgY2FycmllcyBhbiBvcHRpb25hbCBJTlRFUlZBTF9USU1F IFRMViwgaXQgTVVTVCBoYXZlIGEgdmFsdWUgZW5jb2RpbmcgdGhlJm5ic3A7U1JfVENfSU5URVJW QUwuPC9pPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHByZWZlciBrZWVwaW5nIHRoZSBN VVNUIE5PVCBhcHBsaWVkIHRvIG5laWdoYm91ciBhZGRyZXNzIOKAlCBvciBlbHNlLCBpdCBoYXMg cG9zc2liaWxpdHkgb2Ygc2V0dGluZyBsb25nZXIgdmFsaWRpdHkgdGltZSBvZiByZWxhdGVkIGFk ZHJlc3Nlcywgd2hpY2ggaXMgc29tZXRoaW5nIHRoYXQgd2UgZG9u4oCZdCBpbnRlbmQgdG8gZG8u Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk90aGVyIGlzc3VlcyB3aWxsIGJlIGZpeGVkIGluIHRoZSB1cGRhdGVkIHJldmlzaW9uIGFs c28uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmJlc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Smlhemk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0aW9u IDguMiBTUl90aW1lLiBXZSBoYXZlbuKAmXQgcHV0IGluIHBsYWNlIHRoZSBjb25kaXRpb24gdGhh dCB3ZSBuZXZlciByZWR1Y2UgdmFsaWRpdHkgdGltZXMgaW4gYW5hbG9nb3VzIHBsYWNlcyBpbiBS RkMgNzE4MSwgc28gSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgbmVlZGVkDQogaGVyZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxhc3QgbGluZSBvbiBwYWdlIDEzIHJv dXRlIC0mZ3Q7IHJvdXRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNlY3Rpb24gOSwgSSB0aGluayB0aGUgU1JfVENfSU5URVJWQUwgYW5kIFNSX0hPTERfVElNRSBj b25zdHJhaW50cyBhcmUgYSBiaXQgbWVzc3ksIGFuZCBtaXNzaW5nIGEgY29uc3RyYWludC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNSX1RDX0lOVEVSVkFMOiBNVVNU IGJlIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byBUQ19JTlRFUlZBTCwgU0hPVUxEIGJlIHNpZ25p ZmljYW50bHkgZ3JlYXRlciB0aGFuIFRDX0lOVEVSVkFMLCBkZWZhdWx0IDEwIHggVENfSU5URVJW QUwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TUl9IT0xEX1RJTUU6 IE1VU1QgYmUgZ3JlYXRlciB0aGFuIFNSX1RDX0lOVEVSVkFMLCBTSE9VTEQgYWxsb3cgZm9yIGEg c21hbGwgbnVtYmVyIG9mIGxvc3QgbWVzc2FnZXMsIGRlZmF1bHQgaXMgMyB4IFNSX1RDX0lOVEVS VkFMLiAoVGhlcmXigJlzIG5vIG5lZWQgdG8gZGlyZWN0bHkNCiByZWxhdGUgdG8gVENfSU5URVJW QUwgaGVyZS4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+ DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl bGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0IDMzMDAg NDY3NTAwICZuYnNwO3wgJm5ic3A7PGI+RTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb208L3NwYW4+PC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9y ZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhI Ti48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHls ZT0iY29sb3I6IzNBOEI5MiI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl bmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAx MzM3NDUxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1 aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYW5ldA0KIFs8YSBocmVmPSJtYWlsdG86bWFuZXQt Ym91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOm1hbmV0 LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5KaWF6aSBZaTxicj4NCjxiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4xMCBNYXkg MjAxNyAxNToxNjxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+bWFuZXQ8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp OyBaaGVuIENhbzsgUGV0ZXIgWWVlOyBTdXJlc2ggS3Jpc2huYW47IE1pcmphIEvDvGhsZXdpbmQ8 YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+UmU6IFttYW5ldF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYW5ldC1vbHNy djItbXVsdGlwYXRoLTEzLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6 Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp dGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5J TkcgKioqPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0 ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlO2JhY2tncm91bmQtcG9zaXRpb246aW5p dGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8ZW0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ugb3JpZ2lu YXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJu YWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNpZGVyIGNh cmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBh dHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZvciBp bmZvcm1hdGlvbiByZWdhcmRpbmc8L3NwYW4+PC9lbT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvaT48c3Ryb25nPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5SZWQgRmxhZ3M8L3NwYW4+PC9pPjwvc3Ryb25nPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzMzMzk3MiI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+dGhhdA0KIHlvdSBjYW4gbG9vayBvdXQg Zm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2s8L3NwYW4+PC9lbT48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxhIGhyZWY9Imh0dHA6Ly93cy1zaXRlcy5lbnQuYmFlc3lz dGVtcy5jb20vc2l0ZXMvSE9TRUNTdGRzTGlicmFyeS9TdGFuZGFyZHNMaWJyYXJ5L0V2ZXJ5b25l L1JlZCUyMEZsYWdzLnBkZiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aGVyZTwvc3Bhbj48 L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3 MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3UgZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91 cywgcGxlYXNlIGZvbGxvdzwvc3Bhbj48L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHA6Ly93cy1zaXRl cy5lbnQuYmFlc3lzdGVtcy5jb20vc2l0ZXMvSE9TRUNTdGRzTGlicmFyeS9TdGFuZGFyZHNMaWJy YXJ5L0V2ZXJ5b25lL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnRoaXMNCiBwcm9jZXNzPC9zcGFuPjwvYT4uPC9zcGFu PjwvZW0+PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzoxLjBwdCA0 LjBwdCAxLjBwdCA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Kio8 L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+Jm5i c3A7PC9iPjwvc3Bhbj48L3NwYW4+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5X QVJOSU5HPC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2I+PC9zcGFuPjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPioqKjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FWFRFUk5BTCBFTUFJ TCAtLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXphdGlv bjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRl YXIgYWxsLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBqdXN0IHN1Ym1pdHRl ZCBhIG5ldyByZXZpc2lvbiBvZiB0aGUgb2xzcnYyLW11bHRpcGF0aCBkcmFmdCBiYXNlZCBvbiB0 aGUgY29tbWVudHMgcmVjZWl2ZWQgc2luY2UgdGhlIElFVEYgTEMsIG1haW5seSBmcm9tOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaHJpczombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTk0MjYuaHRtbCI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9j dXJyZW50L21zZzE5NDI2Lmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WmhlbjombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L21hbmV0L2N1cnJlbnQvbXNnMTk0MjUuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE5 NDI1Lmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlyamE6Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJy ZW50L21zZzE5NDI0Lmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxOTQyNC5odG1sPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBldGVyOiZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxOTQy My5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJlbnQvbXNnMTk0MjMuaHRtbDwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHZhcm86Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYW5ldC9jdXJyZW50L21zZzE5NDIwLmh0bWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxOTQyMC5odG1sPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U3VyZXNoOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvbWFuZXQvY3VycmVudC9tc2cxOTQzMS5odG1sIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2N1cnJl bnQvbXNnMTk0MzEuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYXBwcmVjaWF0ZSB0aGUgcmV2aWV3IGFu ZCB0aGUgY29tbWVudHMsIHdoaWNoIGNlcnRhaW5seSBoZWxwIGltcHJvdmluZyB0aGUgcXVhbGl0 eSBvZiB0aGUgZHJhZnQgYSBsb3QuIFRoYW5rcyB2ZXJ5IG11Y2ghIEZ1cnRoZXIgZmVlZGJhY2sg aXMgd2VsY29tZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaWF6aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMCBN YXkgMjAxNywgYXQgMTY6MDUsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPndyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE1vYmlsZSBBZC1ob2MgTmV0d29ya3Mgb2YgdGhl IElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7OiBNdWx0aXBhdGggRXh0ZW5zaW9uIGZvciB0aGUgT3B0aW1pemVkIExpbmsg U3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9uIDIgKE9MU1J2Mik8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBdXRob3JzICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogSmlhemkgWWk8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtCZW5vaXQgUGFycmVpbjxicj4NCjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GaWxlbmFtZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs6IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0x My50eHQ8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGFnZXMgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 OiAyNTxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5EYXRlICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzogMjAxNy0wNS0xMDxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyZuYnNwO1Ro aXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbXVsdGlwYXRoIGV4dGVuc2lvbiBmb3IgdGhlIE9wdGlt aXplZCBMaW5rPGJyPg0KJm5ic3A7Jm5ic3A7U3RhdGUgUm91dGluZyBQcm90b2NvbCB2ZXJzaW9u IDIgKE9MU1J2MikgdG8gZGlzY292ZXIgbXVsdGlwbGU8YnI+DQombmJzcDsmbmJzcDtkaXNqb2lu dCBwYXRocywgc28gYXMgdG8gaW1wcm92ZSByZWxpYWJpbGl0eSBvZiB0aGUgT0xTUnYyIHByb3Rv Y29sLjxicj4NCiZuYnNwOyZuYnNwO1RoZSBpbnRlcm9wZXJhYmlsaXR5IHdpdGggT0xTUnYyIGlz IHJldGFpbmVkLjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC8iPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC88L3NwYW4+PC9hPjxicj4NCjxicj4NClRoZXJl IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlw YXRoLTEzIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEzPC9zcGFuPjwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWll dGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aC0xMyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LW9s c3J2Mi1tdWx0aXBhdGgtMTM8L3NwYW4+PC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRo LTEzIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEzPC9zcGFuPjwvYT48 YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmciPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVm PSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L3NwYW4+PC9hPjxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYW5ldEBpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5l dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCnJlY2lwaWVudCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPg0KcmVj aXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBz ZW5kZXIuPGJyPg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJw b3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24uPGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKio8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30DE6334074GLKXM0003vGREEN_-- From nobody Thu May 11 06:34:57 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E7312EC33; Thu, 11 May 2017 06:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmqiRauNaKMw; Thu, 11 May 2017 06:34:46 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096FD126D73; Thu, 11 May 2017 06:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494509491; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=23528; bh=H/4zLfP279G3e/aeZ99wygnxuXRxep7MNTOjWV3v2w0=; b=KcgO1ukhkoPMzovsRBg0BfknNuTjYSG4Ro5Qz/78R85vc3pjxopxYO1FOIkj4yib 8v4/ZIB3N8EZOPWA9EL9nR4liDaLVrWGxHNWLcmigfdrztAmnoQSYg6jJ6SUMeGeSFW ZsJnQ4Mj/dnLSeabZXdyrbZJO1OOH15J0tJnoPeE= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494509491404535.4203669935827; Thu, 11 May 2017 06:31:31 -0700 (PDT) From: Jiazi Yi Message-Id: <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_16FDC0A7-537D-4BC0-8DFC-86CB906ACD70" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 15:31:28 +0200 In-Reply-To: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> Cc: The IESG , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org To: Warren Kumari References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 13:34:49 -0000 --Apple-Mail=_16FDC0A7-537D-4BC0-8DFC-86CB906ACD70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Warren,=20 Thanks very much for the comments. Please check our reply inline:=20 > On 10 May 2017, at 17:35, Warren Kumari wrote: >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-manet-olsrv2-multipath-13: No Objection >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I am not a MANET person, and know very little about the Optimized Link > State Routing Protocol, however I found this document to be very vague > and poorly worded in many places. At some point I simply gave up = trying > to understand it, but have concerns that it is not sufficiently clear = for > independent implementations.=20 >=20 > I almost made these a DISCUSS, but, as I said, I'm not a OLSR person, = and > so I'm trusting Alvaro to know if it is deployable / implementable As an extension of OLSRv2, some background on OLSRv2 is probably = necessary to fully understand the document. We will try our best to = clarify related issues in the next revision.=20 Regarding the deployability and implementability, as we mentioned in = section 10 - Implementation Status of the draft, there have been several = open source implementations and those are tested in both real testbed = and simulators. There are also non-trivial amount of academic = publications related to this work:=20 = https://scholar.google.fr/scholar?oi=3Dbibs&hl=3Den&cites=3D10113725695151= 775552 = = https://scholar.google.fr/scholar?oi=3Dbibs&hl=3Den&cites=3D37287066346241= 65938 = So we can safely say that it=E2=80=99s deployable / implementable ;) >=20 > Comments:=20 > S1.1:=20 > "The multi-path extension for OLSRv2 is expected to be revised and > improved to the Standard Track," - I'm not sure an extension can be > "improved to the Standard Track" - perhaps you mean that the documents > will be improved and published as Standards track? Or that once > implementations are more stable they will be documented on Standards > Track? Yeah. As an experimental document, we would like to gather more = experience on related issues, and once mature enough, push the idea on = standards track (like OLSR and OLSRv2).=20 We also rephrased the text in the draft.=20 >=20 > "Although with existing experience, multiple paths can be obtained = even > with such partial information, the calculation might be impacted, > depending on the MPR selection algorithm used." - I don't understand = the > "with existing experience", and this sentence is a fragment. I suspect > that removing " with existing experience," would make this cleaner, = but I > don't really understand what you are trying to say=E2=80=A6 Does this sound better: Although multiple paths can be obtained even with such partial = information based on existing experience, the calculation might be = impacted depending on the Multi-Point Relay (MPR) selection algorithm = used.=20 >=20 > "Different algorithms to obtain multiple paths, other than the default > Multi-path Dijkstra algorithm introduced in this specification." - = this > should have a reference to somewhere in the document. fixed >=20 >=20 > 5.1: > "CUTOFF_RATIO The ratio that defines the maximum metric of a path > compared to the shortest path kept in the OLSRv2 Routing Set. For > example, the metric to a destination is R_metric based on the > Routing Set." - I don't understand what the last sentence is trying = to > say.=20 >=20 > "CUTOFF_RATIO MUST be greater than or > equal to 1. Note that setting the value to 1 means looking for > equal length paths, which may not be possible in some networks." > -- surely setting it to 2 (or any other number) will also end up > looking for paths which might not be possible? > E.g: > =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90 =20 > = =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1=E2=94=82= =E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R3=E2=94=9C= =E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=90 =20 > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2= =94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2= =94=80=E2=94=98 =E2=96=BC =20 > =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94= =80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94= =90 > =E2=94=82 S = =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2=94=82=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82 > =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94= =98 >=20 Yes. This is intentional: to avoid having too much variance between = multiple paths obtained.=20 > "SR_HOLD_TIME_MULTIPLIER The multiplier to calculate the minimal time > that a SR-OLSRv2 Router Tuple SHOULD be kept in the SR-OLSRv2 > Router Set. It is the value of the Message TLV with Type =3D > SOURCE_ROUTE." - this is vague / confusing. I think that you need = a > reference to Sec 6.1.1.=20 In the new revision, this parameter is removed based on the discussion = with Chris at = https://www.ietf.org/mail-archive/web/manet/current/msg19426.html = >=20 >=20 > 9. Configuration Parameters > "the users of this protocol > are also encouraged to explore different parameter setting in = various > network environments, and provide feedback." -- where? Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You meant where = to provide the feedback? There is contact information of the authors in = the draft, and apparently, the mailing list is the right place also. If = you want, we can call it out explicitly in the draft.=20 >=20 >=20 > 12. "IANA Considerations > This section adds one new Message TLV, allocated as a new Type > Extension to an existing Message TLV." > -- this section seems to be missing some important information, like > which registry this updates Message Type 7 in. The registry is "Message TLV Types=E2=80=9D specified in = https://tools.ietf.org/html/rfc7631 = We will add related information in the new revision.=20 best Jiazi >=20 >=20 >=20 >=20 > Nits:=20 > S1.1: >=20 > "Because the packet drop is normally bursty in a path" -- "Because = packet > drops on a path are normally bursty"... >=20 > "Other than general experiences including the protocol specification = and > interoperability with base OLSRv2 implementations, the experiences in = the > following aspects are highly appreciated:" > s/ experiences including/ experiences, including / (grammar) > s/ the experiences / experiences / (grammar) >=20 > "Although with existing experience, multiple paths can be obtained = even > with such partial information, the calculation might be impacted, > depending on the MPR selection algorithm used." > s/Although with existing experience/Although, with existing = experience/ > (grammar) >=20 > "In scenarios where the length of the source routing header is = critical, > the loose source routing can be considered." > s/ the loose source / loose source / >=20 > "for example, the paths with lower metrics (i.e., higher quality) can > transfer more datagrams compared to paths with higher metrics." -- = nit:=20 > many people (perhaps incorrectly) associate 'datagram' with 'UDP' - = you > might want to clarify (or just say packet) >=20 > S3: > "MP-OLSRv2 is designed for networks with dynamic topology by avoiding > single route failure." - this makes it sound like it was *designed* by > avoiding single route failure. >=20 > "in IPv4 networks the interoperability is achieved by using loose = source > routing header;" - in IPv4 networks interoperability is achieved using > loose source routing headers;" (or "by using the loose...") >=20 > S4: > "The reactive operation is local in the router" - "local to the = router" >=20 >=20 > S5.1:=20 > "All the intermediate routers MUST be included in the source routing > header, which makes the number of hops to be kept a variable." > -- I don't understand how the "the number of hops to be kept" is "a > variable"; this makes it sound like I can set the number of hops to be > kept. Perhaps you meant "a variable number of hops" or "the number of > hops changes"? >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_16FDC0A7-537D-4BC0-8DFC-86CB906ACD70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Warren, 

Thanks very much for the comments. = Please check our reply inline: 

On 10 May 2017, at 17:35, = Warren Kumari <warren@kumari.net> wrote:

Warren= Kumari has entered the following ballot position for
draft-ietf-manet-olsrv2-multipath-13: No Objection

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I am not a MANET person, and know = very little about the Optimized Link
State Routing = Protocol, however I found this document to be very vague
and= poorly worded in many places. At some point I simply gave up trying
to understand it, but have concerns that it is not = sufficiently clear for
independent implementations.

I almost made these a DISCUSS, but, as I said, = I'm not a OLSR person, and
so I'm trusting Alvaro to know = if it is deployable / implementable

As an = extension of OLSRv2, some background on OLSRv2 is probably necessary to = fully understand the document. We will try our best to clarify related = issues in the next revision. 

Regarding the deployability and implementability, = as we mentioned in section 10 - Implementation Status of the draft, = there have been several open source implementations and those are tested = in both real testbed and simulators. There are also non-trivial amount = of academic publications related to this work: 


So we = can safely say that it=E2=80=99s deployable / implementable ;)


Comments:
S1.1:
"The multi-path extension for OLSRv2 is expected to be = revised and
improved to the Standard Track," - I'm not = sure an extension can be
"improved to the Standard Track" = - perhaps you mean that the documents
will be improved and = published as Standards track? Or that once
implementations = are more stable they will be documented on Standards
Track?

Yeah. As an experimental document, we would like = to gather more experience on related issues, and once mature enough, = push the idea on standards track (like OLSR and = OLSRv2). 
We also rephrased the text in the = draft. 


"Although with existing = experience, multiple paths can be obtained even
with such = partial information,  the calculation might be impacted,
depending on the MPR selection algorithm used." - I don't = understand the
"with existing experience", and this = sentence is a fragment. I suspect
that removing " with = existing experience," would make this cleaner, but I
don't = really understand what you are trying to = say=E2=80=A6

Does = this sound better:

Although multiple paths can be = obtained even with such partial information based on existing = experience, the calculation might be impacted depending on the = Multi-Point Relay (MPR) selection algorithm = used. 


"Different algorithms to obtain multiple paths, other than = the default
Multi-path Dijkstra algorithm introduced in = this specification." - this
should have a reference to = somewhere in the document.
fixed



5.1:
"CUTOFF_RATIO   The ratio that = defines the maximum metric of a path
compared to the = shortest path kept in the OLSRv2 Routing Set. For
=  example, the metric to a destination is R_metric based on the
 Routing Set." - I don't understand what the last = sentence is trying to
say.

= "CUTOFF_RATIO MUST be greater than or
=      equal to 1.  Note that setting the = value to 1 means looking for
=      equal length paths, which may not be = possible in some networks."
 -- surely setting it to = 2 (or any other number) will also end up
looking for paths = which might not be possible?
 E.g:
=        =E2=94=8C=E2=94=80=E2=94=80=E2=94= =90  =E2=94=8C=E2=94=80=E2=94=80=E2=94=90  =E2=94=8C=E2=94=80=E2= =94=80=E2=94=90  =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =        
=  =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1=E2= =94=82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R3=E2= =94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=90  
 =E2=94=82 =     =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =  =E2=94=94=E2=94=80=E2=94=80=E2=94=98  =E2=94=94=E2=94=80=E2=94=80= =E2=94=98  =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =     =E2=96=BC  
=E2=94=8C=E2=94=80=E2= =94=80=E2=94=80=E2=94=90 =            =E2=94=8C= =E2=94=80=E2=94=80=E2=94=90 =            =E2=94=8C= =E2=94=80=E2=94=80=E2=94=80=E2=94=90
=E2=94=82 S = =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2=94=82=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82
=E2=94=94=E2=94=80= =E2=94=80=E2=94=80=E2=94=98 =            =E2=94=94= =E2=94=80=E2=94=80=E2=94=98 =            =E2=94=94= =E2=94=80=E2=94=80=E2=94=80=E2=94=98


Yes. = This is intentional: to avoid having too much variance between multiple = paths obtained. 

"SR_HOLD_TIME_MULTIPLIER =  The multiplier to calculate the minimal time
=      that a SR-OLSRv2 Router Tuple SHOULD be = kept in the SR-OLSRv2
=      Router Set. It is the value of the Message = TLV with Type =3D
=      SOURCE_ROUTE." - this is vague / = confusing. I think that you need a
reference to Sec 6.1.1. =

In = the new revision, this parameter is removed based on the discussion with = Chris at https://www.ietf.org/mail-archive/web/manet/current/msg19426.ht= ml




9.  Configuration Parameters
"the users of this protocol
  are = also encouraged to explore different parameter setting in various
network environments, and provide feedback."  -- = where?

Hmmm=E2=80=A6 I didn=E2=80=99t quite get the = question. You meant where to provide the feedback? There is contact = information of the authors in the draft, and apparently, the mailing = list is the right place also. If you want, we can call it out explicitly = in the draft. 



12.  "IANA Considerations
=   This section adds one new Message TLV, allocated as a new = Type
  Extension to an existing Message = TLV."
 -- this section seems to be missing some = important information, like
which registry this updates = Message Type 7 in.

The registry is "Message TLV Types=E2=80=9D = specified in https://tools.ietf.org/html/rfc7631
We will add = related information in the new revision. 

best

Jiazi





Nits:
S1.1:

"Because the packet drop is normally bursty in = a path" -- "Because packet
drops on a path are normally = bursty"...

"Other than general experiences = including the protocol specification and
interoperability = with base OLSRv2 implementations, the experiences in the
following aspects are highly appreciated:"
s/ = experiences including/ experiences, including / (grammar)
s/= the experiences / experiences / (grammar)

"Although with existing experience,  multiple paths can = be obtained even
with such partial information,  the = calculation might be impacted,
depending on the MPR = selection algorithm used."
s/Although with existing = experience/Although, with existing experience/
(grammar)

"In scenarios where the length of the source = routing header is critical,
the loose source routing can = be considered."
s/ the loose source /  loose source = /

"for  example, the paths with lower = metrics (i.e., higher quality) can
transfer more datagrams = compared to paths with higher metrics." -- nit:
many = people (perhaps incorrectly) associate 'datagram' with 'UDP' - you
might want to clarify (or just say packet)

S3:
"MP-OLSRv2 is designed for networks with = dynamic topology by avoiding
single route failure." - this = makes it sound like it was *designed* by
avoiding single = route failure.

"in IPv4 networks the = interoperability is achieved by using loose source
routing = header;" - in IPv4 networks interoperability is achieved using
loose source routing headers;" (or "by using the = loose...")

S4:
"The reactive = operation is local in the router" - "local to the router"


S5.1:
"All the = intermediate routers MUST be included in the source routing
header, which makes the number of hops to be kept a = variable."
-- I don't understand how the "the number of = hops to be kept" is "a
variable"; this makes it sound like = I can set the number of hops to be
kept. Perhaps you meant = "a variable number of hops" or "the number of
hops = changes"?


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

= --Apple-Mail=_16FDC0A7-537D-4BC0-8DFC-86CB906ACD70-- From nobody Thu May 11 07:03:11 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691A2129B11; Thu, 11 May 2017 07:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aUrkrFKcxLF; Thu, 11 May 2017 07:03:03 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62EA12F28C; Thu, 11 May 2017 06:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494511059; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=1705; bh=BelNm2oIajbpJp180LItyagffuAxpAlYJyI2OkqrM9o=; b=rwf7WH9l16HogVgFskOfZnwTACTlUsZIWJzyykCcB6e9jnz2iAV2y4haPzY/uyRx C5ZZwMTpSPmM2+ni6w6zwkAeGlLSC7q0vmoZOWlXUvcQfihfomOsgs2cfd0aNPWtdxW CFJgIe6poQf8ObjzdjW510spwOrNU+5xH30JANz0= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494511059856276.89516411504417; Thu, 11 May 2017 06:57:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jiazi Yi In-Reply-To: <149448320721.16690.6113367666672173681.idtracker@ietfa.amsl.com> Date: Thu, 11 May 2017 15:57:35 +0200 Cc: The IESG , manet , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <2D71EF34-E4E5-43D2-B1FD-AE31A6C0073A@jiaziyi.com> References: <149448320721.16690.6113367666672173681.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Adam Roach's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:03:11 -0000 Dear Adam,=20 We appreciate your review and comments.=20 > On 11 May 2017, at 08:13, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-manet-olsrv2-multipath-13: No Objection >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I reviewed the -12 version of this document, and had a comment I was > going to make about dropping packets when no contiguous path of > source-routing capable routers existed between the endpoints; but when = I > went to quote the offending text, discovered that it has been fixed in > the ink-is-still-wet -13 version of the document, dropped one day = before > the telechat.=20 >=20 > To highlight for anyone else who has similarly reviewed the -12 = version: > the only other non-editorial change I find is that avoiding = fragmentation > has been demoted from normative to non-normative (see the last two > paragraphs of section 8.4). My intuition is that fragmentation is > sufficiently disruptive that normative language is called for here, = but I > don't feel strongly about it. As you mentioned, the normative language was used in the -12 revision. = It was changed to non-normative based on the comments received from IETF = LC (IIRC, from Alvaro?). Generally speaking, fragmentation is harmful, but it won=E2=80=99t break = the network. I=E2=80=99m fine with both.=20 best Jiazi >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu May 11 07:16:57 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED69129409; Thu, 11 May 2017 07:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDt3kLG8ESWA; Thu, 11 May 2017 07:16:46 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A8412FC15; Thu, 11 May 2017 07:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494511825; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=8878; bh=QRGXXnb0NtrMYBndFiTlI0RIZp8zAJye9cSB7pwL0Ww=; b=LVY+ZVClIEXooexHILY7T5+Eo2wSd2xkZGZoC2LAiq1dhxB5fnC3OpYx91WFt789 zK4zYOtxjlBdhiLKRJsG/HwHGs2j/rkJydiIxIksjUt7otWWGUGemzTTiVmj6Jjmu3n 6NNdel6/gFeuH7WMW8nM+OvmsxD7D/fExJBZzR28= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494511825304355.26250910429405; Thu, 11 May 2017 07:10:25 -0700 (PDT) From: Jiazi Yi Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A8363719-BA1B-45E1-9A96-D3136A16AC47" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 16:10:23 +0200 In-Reply-To: <1ea04d3a-2446-dcaa-e5b6-21797a3caa57@pi.nu> Cc: "" , "rtg-dir@ietf.org" , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org To: Loa Andersson References: <1ea04d3a-2446-dcaa-e5b6-21797a3caa57@pi.nu> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] RtgDir review of draft-ietf-manet-olsrv2-multipath-12.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:16:49 -0000 --Apple-Mail=_A8363719-BA1B-45E1-9A96-D3136A16AC47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Loa,=20 Thanks a lot for the review.=20 I don=E2=80=99t know why the nits tool says -- Looks like a reference, but probably isn't: '1' on line 469 -- Looks like a reference, but probably isn't: '2' on line 469 because there is no =E2=80=981=E2=80=99/=E2=80=982=E2=80=99 on line 469 = of the draft. May be the RFC editor could tell us what=E2=80=99s the = problem.=20 And we will fix the rest of the issues that you raised in the next = revision.=20 best Jiazi > On 11 May 2017, at 10:14, Loa Andersson wrote: >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. >=20 > Document: draft-ietf-manet-olsrv2-multipath-12.txt > Reviewer: Loa Andersson > Review Date: 2017-05-11 > IETF LC End Date: 2015-05-11 (?) > Intended Status: Experimental >=20 > Summary: >=20 > This document is basically ready for publication, but has nits that = should be considered prior to publication. >=20 > Comments: >=20 > The draft is well written and readable also for someone that does > not read manet-draft that often. >=20 > Major Issues: > "No major issues found. >=20 > Minor Issues: >=20 > "No minor issues found." >=20 > Nits: >=20 > I've looked at the the GenArt review by Peter Yee and the Intdir > review by Zhen Cao and largely agree with their comments. >=20 > In addition: The nits tool picks on something that looks like > references on line 469 ( [1] and [2] ) but is not. Don't think you'll > need to fix that, the RFC Editor will fix if necessary. >=20 > I'd like to have the Abstract fleshed out a bit, some more context > given. If you are new to the area and the draft it is very hard to > find the expected useful info in the abstract. >=20 > You use "TC message" already in section 4, but TC (Traffic Control) > is not expanded until section 6, should be done the first time it is > used. >=20 > The abbreviation "SR" is used (often as part of parameter names), but > never really expanded, though one can find the expansion kind of > explained at some places. Could be made clearer. >=20 > /Loa >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_A8363719-BA1B-45E1-9A96-D3136A16AC47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Loa, 

Thanks a lot for the = review. 

I = don=E2=80=99t know why the nits tool says

  -- Looks like a reference, but =
probably isn't: '1' on line 469

  -- Looks like a reference, but probably isn't: '2' on line =
469

because there is no =E2=80=981=E2=80=99/=E2=80=982=E2=80=99 = on line 469 of the draft. May be the RFC editor could tell us what=E2=80=99= s the problem. 

And we will fix the rest of the issues that you raised in the = next revision. 

best

Jiazi

On 11 May 2017, at 10:14, Loa Andersson = <loa@pi.nu> = wrote:

Hello,

I have been selected as = the Routing Directorate reviewer for this draft. The Routing Directorate = seeks to review all routing or routing-related drafts as they pass = through IETF last call and IESG review, and sometimes on special = request. The purpose of the review is to provide assistance to the = Routing ADs. For more information about the Routing Directorate, please = see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the = use of the Routing ADs, it would be helpful if you could consider them = along with any other IETF Last Call comments that you receive, and = strive to resolve them through discussion or by updating the draft.

Document: = draft-ietf-manet-olsrv2-multipath-12.txt
Reviewer: Loa = Andersson
Review Date: 2017-05-11
IETF LC = End Date: 2015-05-11 (?)
Intended Status: Experimental

Summary:

This = document is basically ready for publication, but has nits that should be = considered prior to publication.

Comments:
The draft is well written and readable also = for someone that does
not read manet-draft that often.

Major Issues:
"No major issues = found.

Minor Issues:

"No minor issues found."

Nits:

I've looked at the the GenArt review by Peter = Yee and the Intdir
review by Zhen Cao and largely agree = with their comments.

In addition: The nits = tool picks on something that looks like
references on line = 469 ( [1] and [2] ) but is not. Don't think you'll
need to = fix that, the RFC Editor will fix if necessary.

I'd like to have the Abstract fleshed out a bit, some more = context
given. If you are new to the area and the draft it = is very hard to
find the expected useful info in the = abstract.

You use "TC message" already in = section 4, but TC (Traffic Control)
is not expanded until = section 6, should be done the first time it is
used.

The abbreviation "SR" is used (often as part = of parameter names), but
never really expanded, though one = can find the expansion kind of
explained at some places. = Could be made clearer.

/Loa

--


Loa Andersson =             &n= bsp;          email: = loa@mail01.huawei.com
Senior MPLS Expert =             &n= bsp;           &nbs= p;loa@pi.nu
Huawei Technologies (consultant) =     phone: +46 739 81 21 64

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

= --Apple-Mail=_A8363719-BA1B-45E1-9A96-D3136A16AC47-- From nobody Thu May 11 07:25:57 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549AC13145C for ; Thu, 11 May 2017 07:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGtiMxH6--Za for ; Thu, 11 May 2017 07:25:52 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411CB131489 for ; Thu, 11 May 2017 07:18:17 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id g23so2017110vke.3 for ; Thu, 11 May 2017 07:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mq+2b3rmZhGNVwkYwEQij5cj0ubXD51fmYpQgGGIm+w=; b=dDXFRTu33uW06pfBFxfXAGGx3HWnxH4gvKRgMDd4klLcU4lhU8u9NFs2FotazfHrYa g0x3jaX7zxwACgAt1PnOP+Oja/cAIGhR0DuyrUXtjj4ZfpDQVS+cZ7CEd/aw340VK9a5 AJcK9EwXepRW/ta9qZJ76q9rf5oNOHb2y3DLfan52RV0XY9li0kyXoKK/Bs9zbXRMoKq OHbRcHTrFNBqF3HBg28l2/3tpExt/PNideRjHHN+GWKDYAsBlKwUq4l8KlSq69h3f0AK E0s+f7unSVkWilfR6WyMXdTDFo9ODZk6g2IRYD40NCeIW3XHZjQs/r6CilYb79rW7tcl olDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mq+2b3rmZhGNVwkYwEQij5cj0ubXD51fmYpQgGGIm+w=; b=uebuMJ9KvK43yEpO9MvMHLpj9E2NzFQP9w8QVL9BxO8V7QxlmF4cOt1CIHHuN/m2hY O5lLZ/m5eA2cgb4eeQHOlvOZc8ylQNBiTg0hmawTRftnwC3LXMFNrhKTXCtp/MJ4vv+x nu5UpPIbld3kI0X+jQAznBRrZI6WssBQuWkuTuydVQae9IkxMML7va5GyJXQTaH7X9wn 28wOD5EGxb07xuLe236AT/WEyk5IPEH8xaSUX+SRhlLdfHrGIxoBkTUiMGMkF8Z6RDia uPmfM8Tv3yHSmOHBCWNERrB6QbSYAOcmu60q7rFFI0fyoE9u1Q/mO6iBGkjuncfL40uM oYcQ== X-Gm-Message-State: AODbwcCHY9NqfRmsACoGtwXC7dCVhHLqCe6rWarSyVYZFUuHjzYumTdz W+N3CFPDr6MoMyLwhVJxBfgxxMHbBWCD X-Received: by 10.31.3.77 with SMTP id 74mr267454vkd.80.1494512296020; Thu, 11 May 2017 07:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.83 with HTTP; Thu, 11 May 2017 07:17:35 -0700 (PDT) In-Reply-To: <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> From: Warren Kumari Date: Thu, 11 May 2017 16:17:35 +0200 Message-ID: To: Jiazi Yi Cc: The IESG , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:25:55 -0000 On Thu, May 11, 2017 at 3:31 PM, Jiazi Yi wrote: > Dear Warren, > > Thanks very much for the comments. Please check our reply inline: > > On 10 May 2017, at 17:35, Warren Kumari wrote: > > Warren Kumari has entered the following ballot position for > draft-ietf-manet-olsrv2-multipath-13: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am not a MANET person, and know very little about the Optimized Link > State Routing Protocol, however I found this document to be very vague > and poorly worded in many places. At some point I simply gave up trying > to understand it, but have concerns that it is not sufficiently clear for > independent implementations. > > I almost made these a DISCUSS, but, as I said, I'm not a OLSR person, and > so I'm trusting Alvaro to know if it is deployable / implementable > > > As an extension of OLSRv2, some background on OLSRv2 is probably necessar= y > to fully understand the document. We will try our best to clarify related > issues in the next revision. > > Regarding the deployability and implementability, as we mentioned in sect= ion > 10 - Implementation Status of the draft, there have been several open sou= rce > implementations and those are tested in both real testbed and simulators. Excellent. I'll be honest - I stopped reading before Sec 10, and then skipped down to the end.... > There are also non-trivial amount of academic publications related to thi= s > work: > > https://scholar.google.fr/scholar?oi=3Dbibs&hl=3Den&cites=3D1011372569515= 1775552 > https://scholar.google.fr/scholar?oi=3Dbibs&hl=3Den&cites=3D3728706634624= 165938 > > So we can safely say that it=E2=80=99s deployable / implementable ;) > > > Comments: > S1.1: > "The multi-path extension for OLSRv2 is expected to be revised and > improved to the Standard Track," - I'm not sure an extension can be > "improved to the Standard Track" - perhaps you mean that the documents > will be improved and published as Standards track? Or that once > implementations are more stable they will be documented on Standards > Track? > > > Yeah. As an experimental document, we would like to gather more experienc= e > on related issues, and once mature enough, push the idea on standards tra= ck > (like OLSR and OLSRv2). > We also rephrased the text in the draft. Thanks. > > > "Although with existing experience, multiple paths can be obtained even > with such partial information, the calculation might be impacted, > depending on the MPR selection algorithm used." - I don't understand the > "with existing experience", and this sentence is a fragment. I suspect > that removing " with existing experience," would make this cleaner, but I > don't really understand what you are trying to say=E2=80=A6 > > > Does this sound better: > > Although multiple paths can be obtained even with such partial informatio= n > based on existing experience, the calculation might be impacted depending= on > the Multi-Point Relay (MPR) selection algorithm used. > I think, "Experience has shown that multiple paths can be obtained even with such partial information, however, depending on the Multi-Point Relay (MPR) selection algorithm used, the calculation might be impacted". I'm not quite sure what you mean by: "calculation might be impacted" - perhaps "suboptimal results may be obtained"? Or something. > > > "Different algorithms to obtain multiple paths, other than the default > Multi-path Dijkstra algorithm introduced in this specification." - this > should have a reference to somewhere in the document. > > > fixed Thanks > > > > 5.1: > "CUTOFF_RATIO The ratio that defines the maximum metric of a path > compared to the shortest path kept in the OLSRv2 Routing Set. For > example, the metric to a destination is R_metric based on the > Routing Set." - I don't understand what the last sentence is trying to > say. > > "CUTOFF_RATIO MUST be greater than or > equal to 1. Note that setting the value to 1 means looking for > equal length paths, which may not be possible in some networks." > -- surely setting it to 2 (or any other number) will also end up > looking for paths which might not be possible? > E.g: > =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94= =80=E2=94=90 > =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1=E2=94= =82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R3=E2= =94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=90 > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80= =E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=96=BC > =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94= =80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94= =90 > =E2=94=82 S =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2=94= =82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82 > =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94= =98 > > > Yes. This is intentional: to avoid having too much variance between multi= ple > paths obtained. Yup, but if set to 2, you might also not be able to find a path that works, so I think you need to remove: "Note that setting the value to 1 means looking for equal length paths, which may not be possible in some networks." -- or perhaps, "Setting the number low makes it less likely that additional paths will be found -- for example, setting it to 1 will only consider equal length paths" ? (I don't feel strongly about any of this) > > "SR_HOLD_TIME_MULTIPLIER The multiplier to calculate the minimal time > that a SR-OLSRv2 Router Tuple SHOULD be kept in the SR-OLSRv2 > Router Set. It is the value of the Message TLV with Type =3D > SOURCE_ROUTE." - this is vague / confusing. I think that you need a > reference to Sec 6.1.1. > > > In the new revision, this parameter is removed based on the discussion wi= th > Chris at https://www.ietf.org/mail-archive/web/manet/current/msg19426.htm= l > Great, thanks. > > 9. Configuration Parameters > "the users of this protocol > are also encouraged to explore different parameter setting in various > network environments, and provide feedback." -- where? > > > Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You meant where to= provide the > feedback? There is contact information of the authors in the draft, and > apparently, the mailing list is the right place also. If you want, we can > call it out explicitly in the draft. Yup, that would be great -- perhaps "and provide feedback to the MANET WG " ID Guidlines contains: "It is strongly recommended that the draft include a notice (with email address) of where comments should be sent. For example: "Comments are solicited and should be addressed to the working group's mailing list at ___@______ and/or the author(s)." " -- perhaps just copy that. Actually, chairs, do you want this (don't want to clutter up your list). > > > > 12. "IANA Considerations > This section adds one new Message TLV, allocated as a new Type > Extension to an existing Message TLV." > -- this section seems to be missing some important information, like > which registry this updates Message Type 7 in. > > > The registry is "Message TLV Types=E2=80=9D specified in > https://tools.ietf.org/html/rfc7631 > We will add related information in the new revision. Win! > > best > > Jiazi > Awesome, thank you for addressing all these... W > > > > > Nits: > S1.1: > > "Because the packet drop is normally bursty in a path" -- "Because packet > drops on a path are normally bursty"... > > "Other than general experiences including the protocol specification and > interoperability with base OLSRv2 implementations, the experiences in the > following aspects are highly appreciated:" > s/ experiences including/ experiences, including / (grammar) > s/ the experiences / experiences / (grammar) > > "Although with existing experience, multiple paths can be obtained even > with such partial information, the calculation might be impacted, > depending on the MPR selection algorithm used." > s/Although with existing experience/Although, with existing experience/ > (grammar) > > "In scenarios where the length of the source routing header is critical, > the loose source routing can be considered." > s/ the loose source / loose source / > > "for example, the paths with lower metrics (i.e., higher quality) can > transfer more datagrams compared to paths with higher metrics." -- nit: > many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you > might want to clarify (or just say packet) > > S3: > "MP-OLSRv2 is designed for networks with dynamic topology by avoiding > single route failure." - this makes it sound like it was *designed* by > avoiding single route failure. > > "in IPv4 networks the interoperability is achieved by using loose source > routing header;" - in IPv4 networks interoperability is achieved using > loose source routing headers;" (or "by using the loose...") > > S4: > "The reactive operation is local in the router" - "local to the router" > > > S5.1: > "All the intermediate routers MUST be included in the source routing > header, which makes the number of hops to be kept a variable." > -- I don't understand how the "the number of hops to be kept" is "a > variable"; this makes it sound like I can set the number of hops to be > kept. Perhaps you meant "a variable number of hops" or "the number of > hops changes"? > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu May 11 08:28:16 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F3C131459; Thu, 11 May 2017 08:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4xzgXSsEirI; Thu, 11 May 2017 08:28:12 -0700 (PDT) Received: from mail-yb0-x243.google.com (mail-yb0-x243.google.com [IPv6:2607:f8b0:4002:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A736C12EB8C; Thu, 11 May 2017 08:22:57 -0700 (PDT) Received: by mail-yb0-x243.google.com with SMTP id 19so1032557ybl.2; Thu, 11 May 2017 08:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IFsJqiu6wIgpJuNom1AlcYsBaE4luVn0u0POQlB/eZg=; b=rsiQD3sinMzi7/vicQBupvZDZIzWXujDHhw1k5a+k+Si8dEeqCLLJUCElD5FX3mJMM 74hBbDctaODDianuRiPO9u21hNnySuJ1fCt0aWdtGAI2grAoQfvC0dWpwiIw60Ch61sD HSIUW8bEQriC13vxxB3x4DYtpcMRdfro0Rw9BWeXWPDZrianh8JiSyGATGky5CcjuAJx f8AZpim3pbTSKprqVRDz+3aoqmOCs93WtRdGBELGY8QeARzP71tE5clGKxEMg/3stMyM wRfUksov3RS2G3ZvZu2KlOPnQbjA3nG4sl0t0cdqB2mr949sMg+fFsaShL3VHakKUDLW G7NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IFsJqiu6wIgpJuNom1AlcYsBaE4luVn0u0POQlB/eZg=; b=MjBAvGWWlDr+jW4rYjhN12yZtILaItodOFtLj8hUMSQAj1d1tc59cweVYJh45Pcigk 8mdpF4Taqc0cZJqZ+mmL7gkbvhrVizrKtky1twykkx26GoM5cEtHotVoG2D5LyO98HYU aM3wlZtLWb0qSWyrMb4QoE69AoWptNt/hm+X2M48r78H+AuDWjmEx0loCLqFr1IB1qDx bx2fXv1aU24nnn1InQU/bieHAamiIoofNS9oXtmP7uJG2RbYHUw4atfHTwy3onqe0vhk ESUes0LEJwQqXvDJY6lG5qerwzKem7DUUImT8hs+GtmoSQiOJQSmuAANIgHp6j2u12jj QnrA== X-Gm-Message-State: AODbwcDnhXZqX96/Utw/GZOQvA3jeCjdD3Q39BH4m/Us/BXqEYueOkVf 32senqQel5BjwlNGAbLFXg== X-Received: by 10.37.202.85 with SMTP id a82mr732984ybg.149.1494516176819; Thu, 11 May 2017 08:22:56 -0700 (PDT) Received: from [10.0.0.2] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id b64sm231691ywe.3.2017.05.11.08.22.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 May 2017 08:22:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> Date: Thu, 11 May 2017 11:22:55 -0400 Cc: The IESG , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> To: Jiazi Yi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 15:28:14 -0000 > On May 10, 2017, at 5:29 AM, Jiazi Yi wrote: >=20 > Dear Suresh,=20 >=20 > Thanks very much for the comments.=20 > Alvaro raised the same issue before =E2=80=94 we will use the type 3 = header in the next revision.=20 Sounds good Jiazi. I did not see this in Alvaro=E2=80=99s ballot and = that is why I commented. I saw version -13 has already fixed this. = Thanks for this. Regards Suresh From nobody Thu May 11 08:45:26 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912CB1314BA; Thu, 11 May 2017 08:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RYYN1zizyaX; Thu, 11 May 2017 08:45:14 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594871314AC; Thu, 11 May 2017 08:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494517140; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=49115; bh=S1hJrEQbdMjfl09hF0DC31P0GdHNLkZJ5CnohRoEjow=; b=Sa2ScBAspONbLkj1iAVqwVo5lvCZnQSuhi1nTh8d0Uw0ulK4YnteaIU6TSQZU0yV MRT3kpksknAQ8Vt5YyJ/h3b57yAxVQ8g11xFMMwkJIvwFuh0lOo4xfAJFNeWo5/4K6J WJNtxkS7GrK8mpdGOEJ+zQDBQVRdA/rgf9RggJEI= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494517140002374.3380521591406; Thu, 11 May 2017 08:39:00 -0700 (PDT) From: Jiazi Yi Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8089B898-3AAD-4425-8DAC-7B1C299EFAE0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 11 May 2017 17:38:57 +0200 In-Reply-To: Cc: The IESG , manet , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group To: Warren Kumari References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 15:45:17 -0000 --Apple-Mail=_8089B898-3AAD-4425-8DAC-7B1C299EFAE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi,=20 >>=20 >> "Although with existing experience, multiple paths can be obtained = even >> with such partial information, the calculation might be impacted, >> depending on the MPR selection algorithm used." - I don't understand = the >> "with existing experience", and this sentence is a fragment. I = suspect >> that removing " with existing experience," would make this cleaner, = but I >> don't really understand what you are trying to say=E2=80=A6 >>=20 >>=20 >> Does this sound better: >>=20 >> Although multiple paths can be obtained even with such partial = information >> based on existing experience, the calculation might be impacted = depending on >> the Multi-Point Relay (MPR) selection algorithm used. >>=20 >=20 > I think, "Experience has shown that multiple paths can be obtained > even with such partial information, however, depending on the > Multi-Point Relay (MPR) selection algorithm used, the calculation > might be impacted=E2=80=9D. Yes.=20 > I'm not quite sure what you mean by: "calculation > might be impacted" - perhaps "suboptimal results may be obtained"? Or > something. It=E2=80=99s the disjointness of the paths calculated. We will clarify = it in the text also.=20 >> 5.1: >> "CUTOFF_RATIO The ratio that defines the maximum metric of a path >> compared to the shortest path kept in the OLSRv2 Routing Set. For >> example, the metric to a destination is R_metric based on the >> Routing Set." - I don't understand what the last sentence is trying = to >> say. >>=20 >> "CUTOFF_RATIO MUST be greater than or >> equal to 1. Note that setting the value to 1 means looking for >> equal length paths, which may not be possible in some networks." >> -- surely setting it to 2 (or any other number) will also end up >> looking for paths which might not be possible? >> E.g: >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90 >> = =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1=E2=94=82= =E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R3=E2=94=9C= =E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=90 >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2= =94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2= =94=80=E2=94=98 =E2=96=BC >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94= =80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94= =90 >> =E2=94=82 S = =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2=94=82=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82 >> =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94= =98 >>=20 >>=20 >> Yes. This is intentional: to avoid having too much variance between = multiple >> paths obtained. >=20 >=20 > Yup, but if set to 2, you might also not be able to find a path that > works, so I think you need to remove: "Note that setting the value to > 1 means looking for equal length paths, which may not be possible in > some networks." -- or perhaps, "Setting the number low makes it less > likely that additional paths will be found -- for example, setting it > to 1 will only consider equal length paths" ? (I don't feel strongly > about any of this) Yeah, this would be better. thanks.=20 >=20 >>=20 >> 9. Configuration Parameters >> "the users of this protocol >> are also encouraged to explore different parameter setting in = various >> network environments, and provide feedback." -- where? >>=20 >>=20 >> Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You meant = where to provide the >> feedback? There is contact information of the authors in the draft, = and >> apparently, the mailing list is the right place also. If you want, we = can >> call it out explicitly in the draft. >=20 >=20 > Yup, that would be great -- perhaps "and provide feedback to the MANET > WG " > ID Guidlines contains: >=20 > "It is strongly recommended that the draft include a notice (with > email address) of where comments should be sent. For example: >=20 > "Comments are solicited and should be addressed to the working > group's mailing list at ___@______ and/or the author(s)." > " > -- perhaps just copy that. Actually, chairs, do you want this (don't > want to clutter up your list). I=E2=80=99m fine with the proposed text, unless the chairs are = explicitly against it ;) Again, thanks very much for the review and the comments! regards Jiazi >=20 >>=20 >>=20 >>=20 >> 12. "IANA Considerations >> This section adds one new Message TLV, allocated as a new Type >> Extension to an existing Message TLV." >> -- this section seems to be missing some important information, like >> which registry this updates Message Type 7 in. >>=20 >>=20 >> The registry is "Message TLV Types=E2=80=9D specified in >> https://tools.ietf.org/html/rfc7631 = >> We will add related information in the new revision. >=20 > Win! >=20 >>=20 >> best >>=20 >> Jiazi >>=20 >=20 > Awesome, thank you for addressing all these... >=20 > W >=20 >>=20 >>=20 >>=20 >>=20 >> Nits: >> S1.1: >>=20 >> "Because the packet drop is normally bursty in a path" -- "Because = packet >> drops on a path are normally bursty"... >>=20 >> "Other than general experiences including the protocol specification = and >> interoperability with base OLSRv2 implementations, the experiences in = the >> following aspects are highly appreciated:" >> s/ experiences including/ experiences, including / (grammar) >> s/ the experiences / experiences / (grammar) >>=20 >> "Although with existing experience, multiple paths can be obtained = even >> with such partial information, the calculation might be impacted, >> depending on the MPR selection algorithm used." >> s/Although with existing experience/Although, with existing = experience/ >> (grammar) >>=20 >> "In scenarios where the length of the source routing header is = critical, >> the loose source routing can be considered." >> s/ the loose source / loose source / >>=20 >> "for example, the paths with lower metrics (i.e., higher quality) = can >> transfer more datagrams compared to paths with higher metrics." -- = nit: >> many people (perhaps incorrectly) associate 'datagram' with 'UDP' - = you >> might want to clarify (or just say packet) >>=20 >> S3: >> "MP-OLSRv2 is designed for networks with dynamic topology by avoiding >> single route failure." - this makes it sound like it was *designed* = by >> avoiding single route failure. >>=20 >> "in IPv4 networks the interoperability is achieved by using loose = source >> routing header;" - in IPv4 networks interoperability is achieved = using >> loose source routing headers;" (or "by using the loose...") >>=20 >> S4: >> "The reactive operation is local in the router" - "local to the = router" >>=20 >>=20 >> S5.1: >> "All the intermediate routers MUST be included in the source routing >> header, which makes the number of hops to be kept a variable." >> -- I don't understand how the "the number of hops to be kept" is "a >> variable"; this makes it sound like I can set the number of hops to = be >> kept. Perhaps you meant "a variable number of hops" or "the number of >> hops changes"? >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf --Apple-Mail=_8089B898-3AAD-4425-8DAC-7B1C299EFAE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, 

<snip>

"Although = with existing experience, multiple paths can be obtained even
with such partial information,  the calculation might be = impacted,
depending on the MPR selection algorithm used." = - I don't understand the
"with existing experience", and = this sentence is a fragment. I suspect
that removing " = with existing experience," would make this cleaner, but I
don't really understand what you are trying to say=E2=80=A6


Does this sound better:

Although multiple paths can be obtained even = with such partial information
based on existing = experience, the calculation might be impacted depending on
the Multi-Point Relay (MPR) selection algorithm used.


I think, "Experience has shown = that multiple paths can be obtained
even with such partial = information, however, depending on the
Multi-Point Relay (MPR) = selection algorithm used, the calculation
might be impacted=E2=80=9D. =

Yes. 

I'm not quite sure what you mean by: = "calculation
might be impacted" - perhaps "suboptimal = results may be obtained"? Or
something.

It=E2=80=99s = the disjointness of the paths calculated. We will clarify it in the text = also. 

<snip>

5.1:
"CUTOFF_RATIO   The ratio that defines the maximum = metric of a path
compared to the shortest path kept in the = OLSRv2 Routing Set. For
example, the metric to a = destination is R_metric based on the
Routing Set." - I = don't understand what the last sentence is trying to
say.
"CUTOFF_RATIO MUST be greater than or
    equal to 1.  Note that setting = the value to 1 means looking for
    equal length paths, which may not be = possible in some networks."
-- surely setting it to 2 (or = any other number) will also end up
looking for paths which = might not be possible?
E.g:
      =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90  =E2=94=8C=E2=94=80=E2=94=80=E2=94=90  =E2=94=8C=E2=94= =80=E2=94=80=E2=94=90  =E2=94=8C=E2=94=80=E2=94=80=E2=94=90
=E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82= R1=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82= R3=E2=94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=90
=E2=94=82 =     =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =  =E2=94=94=E2=94=80=E2=94=80=E2=94=98  =E2=94=94=E2=94=80=E2=94=80= =E2=94=98  =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =     =E2=96=BC
=E2=94=8C=E2=94=80=E2=94=80= =E2=94=80=E2=94=90 =            =E2=94=8C= =E2=94=80=E2=94=80=E2=94=90 =            =E2=94=8C= =E2=94=80=E2=94=80=E2=94=80=E2=94=90
=E2=94=82 S = =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2=94=82=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82
=E2=94=94=E2=94=80= =E2=94=80=E2=94=80=E2=94=98 =            =E2=94=94= =E2=94=80=E2=94=80=E2=94=98 =            =E2=94=94= =E2=94=80=E2=94=80=E2=94=80=E2=94=98


Yes. This is intentional: to avoid having too much variance = between multiple
paths obtained.


Yup, but if set to 2, you might = also not be able to find a path that
works, so I think you need to = remove: "Note that setting the value to
1 means looking for equal length = paths, which may not be possible in
some networks." -- or perhaps, = "Setting the number low makes it less
likely that additional paths = will be found -- for example, setting it
to 1 will only consider equal = length paths" ? (I don't feel strongly
about any of this)

Yeah, this = would be better. thanks. 

<snip>



9. =  Configuration Parameters
"the users of this = protocol
 are also encouraged to explore different = parameter setting in various
network environments, and = provide feedback."  -- where?


Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You = meant where to provide the
feedback? There is contact = information of the authors in the draft, and
apparently, = the mailing list is the right place also. If you want, we can
call it out explicitly in the draft.


Yup, that would be great -- = perhaps "and provide feedback to the MANET
WG <insert list = name>"
ID Guidlines contains:
"It is strongly recommended that the draft = include a notice (with
  email address) of = where comments should be sent.  For example:
     "Comments are = solicited and should be addressed to the working
     group's mailing = list at ___@______ and/or the author(s)."
"
-- perhaps just copy that. =  Actually, chairs, do you want this (don't
want to clutter up your list).

I=E2=80=99m = fine with the proposed text, unless the chairs are explicitly against it = ;)

Again, thanks very much for the = review and the comments!

regards

Jiazi





12.  "IANA Considerations
 This section adds one new Message TLV, allocated as a = new Type
 Extension to an existing Message TLV."
-- this section seems to be missing some important = information, like
which registry this updates Message Type = 7 in.


The registry is = "Message TLV Types=E2=80=9D specified in
https://tools.ietf.org/html/rfc7631
We will = add related information in the new revision.

Win!


best

Jiazi


Awesome, thank you for addressing all = these...

W





Nits:
S1.1:

"Because the packet drop is normally bursty in = a path" -- "Because packet
drops on a path are normally = bursty"...

"Other than general experiences = including the protocol specification and
interoperability = with base OLSRv2 implementations, the experiences in the
following aspects are highly appreciated:"
s/ = experiences including/ experiences, including / (grammar)
s/= the experiences / experiences / (grammar)

"Although with existing experience,  multiple paths can = be obtained even
with such partial information,  the = calculation might be impacted,
depending on the MPR = selection algorithm used."
s/Although with existing = experience/Although, with existing experience/
(grammar)

"In scenarios where the length of the source = routing header is critical,
the loose source routing can = be considered."
s/ the loose source /  loose source = /

"for  example, the paths with lower = metrics (i.e., higher quality) can
transfer more datagrams = compared to paths with higher metrics." -- nit:
many = people (perhaps incorrectly) associate 'datagram' with 'UDP' - you
might want to clarify (or just say packet)

S3:
"MP-OLSRv2 is designed for networks with = dynamic topology by avoiding
single route failure." - this = makes it sound like it was *designed* by
avoiding single = route failure.

"in IPv4 networks the = interoperability is achieved by using loose source
routing = header;" - in IPv4 networks interoperability is achieved using
loose source routing headers;" (or "by using the = loose...")

S4:
"The reactive = operation is local in the router" - "local to the router"


S5.1:
"All the = intermediate routers MUST be included in the source routing
header, which makes the number of hops to be kept a = variable."
-- I don't understand how the "the number of = hops to be kept" is "a
variable"; this makes it sound like = I can set the number of hops to be
kept. Perhaps you meant = "a variable number of hops" or "the number of
hops = changes"?


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




-- 
I don't think the execution is relevant when it = was obviously a bad
idea in the first = place.
This is like putting rabid weasels in = your pants, and later expressing
regret at having chosen those = particular rabid weasels and that pair
of pants.
  ---maf

= --Apple-Mail=_8089B898-3AAD-4425-8DAC-7B1C299EFAE0-- From nobody Thu May 11 13:51:49 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389C113149C; Thu, 11 May 2017 13:51:47 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfQLh43AkuzP; Thu, 11 May 2017 13:51:44 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F72F12EBBC; Thu, 11 May 2017 13:46:10 -0700 (PDT) Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BDC8418014F3; Thu, 11 May 2017 22:46:08 +0200 (CEST) To: Jiazi Yi References: <1ea04d3a-2446-dcaa-e5b6-21797a3caa57@pi.nu> Cc: "" , "rtg-dir@ietf.org" , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org From: Loa Andersson Message-ID: Date: Thu, 11 May 2017 22:46:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [manet] RtgDir review of draft-ietf-manet-olsrv2-multipath-12.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 20:51:47 -0000 Jiazi Inline please On 2017-05-11 16:10, Jiazi Yi wrote: > Hi Loa, > > Thanks a lot for the review. > > I don’t know why the nits tool says > > -- Looks like a reference, but probably isn't: '1' on line 469 > > -- Looks like a reference, but probably isn't: '2' on line 469 line 469 is (i've marked the '1' and '2' 469 (PT_metric, PT_address[1], PT_address[2], ..., PT_address[n]) ~~~ ~~~ My question is really not to the authors, I think your text is fine. RFC Editor might escape the '[' and ']', but I don't really understand why the nits tool does not have a warning for the '[n]' on the same line. I will bring this up witht he tools people. /Loa > > > because there is no ‘1’/‘2’ on line 469 of the draft. May be the RFC > editor could tell us what’s the problem. > > And we will fix the rest of the issues that you raised in the next > revision. > > best > > Jiazi > >> On 11 May 2017, at 10:14, Loa Andersson > >> wrote: >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this >> draft. The Routing Directorate seeks to review all routing or >> routing-related drafts as they pass through IETF last call and IESG >> review, and sometimes on special request. The purpose of the review is >> to provide assistance to the Routing ADs. For more information about >> the Routing Directorate, please see ​ >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, >> it would be helpful if you could consider them along with any other >> IETF Last Call comments that you receive, and strive to resolve them >> through discussion or by updating the draft. >> >> Document: draft-ietf-manet-olsrv2-multipath-12.txt >> Reviewer: Loa Andersson >> Review Date: 2017-05-11 >> IETF LC End Date: 2015-05-11 (?) >> Intended Status: Experimental >> >> Summary: >> >> This document is basically ready for publication, but has nits that >> should be considered prior to publication. >> >> Comments: >> >> The draft is well written and readable also for someone that does >> not read manet-draft that often. >> >> Major Issues: >> "No major issues found. >> >> Minor Issues: >> >> "No minor issues found." >> >> Nits: >> >> I've looked at the the GenArt review by Peter Yee and the Intdir >> review by Zhen Cao and largely agree with their comments. >> >> In addition: The nits tool picks on something that looks like >> references on line 469 ( [1] and [2] ) but is not. Don't think you'll >> need to fix that, the RFC Editor will fix if necessary. >> >> I'd like to have the Abstract fleshed out a bit, some more context >> given. If you are new to the area and the draft it is very hard to >> find the expected useful info in the abstract. >> >> You use "TC message" already in section 4, but TC (Traffic Control) >> is not expanded until section 6, should be done the first time it is >> used. >> >> The abbreviation "SR" is used (often as part of parameter names), but >> never really expanded, though one can find the expansion kind of >> explained at some places. Could be made clearer. >> >> /Loa >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat May 13 05:53:34 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5748912944B for ; Sat, 13 May 2017 05:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.703 X-Spam-Level: X-Spam-Status: No, score=0.703 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvfepx6Jp5zb for ; Sat, 13 May 2017 05:53:29 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195721292AE for ; Sat, 13 May 2017 05:52:05 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id 99so2039700lfu.2 for ; Sat, 13 May 2017 05:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=lxYff2uNmicSWFN3eq95V24jJLKO/JMQpzhPfnOP3KY=; b=VaLNKM6hSRKPTGSVfZ9Wr9JJTloEd4kS3z8sBhE2lmeWUVgUuLA15jGS/bS22J8hS0 4PQIH8dNHO+rMRIjjoGmimlpRyaGKd71iT0/k6kpnzARUoO2bwYoRXcTOywDIC7QebT1 ON8j8dtbdVYjSgADzf3B5wiDrHCP/AsvJhfILLOtQvNiQPm91XyEz4ti76lXj+bgumaq f1QsH8ssxcH8j1YS3U8RSKq7O4OfDWDgzIy+iAwf7tNNnrwFfM7Svr92kNWlzajQgQXa 1Lq42ZXwiMXNC1eGf9SKtOqxCkqYhHj7xj7mVdjqhU/TSkDoC5Awch92QKa7aSdy4hdl dNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=lxYff2uNmicSWFN3eq95V24jJLKO/JMQpzhPfnOP3KY=; b=N/fK+LY4S/Rn2CPlQMuk/5PJD6f4UhjJxDZ46hps+gJGDTCMnoKDPaCk31lZiE9RAO 8gSXHUzl8qoM2klI9OzyzB0gw58K3nQ6bbuo+dgKN8IBfrAZYT/SGC0ufifw5jYLykZg ZNXFheDKHcMZ9r53joUpzv2sHjSgi9irQ2pr4vJbSlUpfOcPLkWh+4xa/iFoEHHxhloo anfVdzXmb6QMoEpbqQlaJcGGHFfztJrlWX46frq+uctys741g+h9dipA6xBigR9/B3Lm zwnooZH7cv2YXSqy3/RdFMmD+JGiqYFZ9XsujJNYn9pGVr18j0/rnJIJnmBDBl+8kO5L 0Cvg== X-Gm-Message-State: AODbwcCjiSpg0J+wuT1ahDK1OhCyQ5TPQP+6Vd4UtsrmuKOZYXatleWZ aBCjrDGCDlbBBRe2dWvv4s8PwQgR3yj1 X-Received: by 10.25.141.212 with SMTP id p203mr3453855lfd.60.1494679923142; Sat, 13 May 2017 05:52:03 -0700 (PDT) Received: from 52669349336 named unknown by gmailapi.google.com with HTTPREST; Sat, 13 May 2017 08:52:02 -0400 MIME-Version: 1.0 Sender: chhagan.iiita@gmail.com From: chhagan.iiita@gmail.com Date: Sat, 13 May 2017 08:52:02 -0400 X-Google-Sender-Auth: McNRMbY_hBPae0xGLW8_k_9Y1os Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary="001a11401b7edf35c8054f67491c" Archived-At: Subject: [manet] =?utf-8?q?=5BWiSec=E2=80=9917=5D_Call_for_Student_Travel_?= =?utf-8?q?Grant_Applications?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2017 12:53:31 -0000 --001a11401b7edf35c8054f67491c Content-Type: text/plain; charset="UTF-8" Dear Students, The 10th ACM Conference on Security and Privacy in Wireless and Mobile Networks (ACM WiSec 2017) to be held from July 18 to July 20, 2017 in Boston, USA is pleased to announce competitive travel grants to attend ACM WiSec 2017 (http://wisec2017.ccs.neu.edu/index.html) Conference and all co-located events such as Poster and Demo sessions. Graduate students with an interest in the areas of mobile and wireless systems security and are interested in attending ACM WiSec 2017 are encouraged to apply for a student travel grant. The conference will partially subsidize travel costs up to $1,000 of those who would otherwise be unable to attend. More information and application instructions are available on the conference website: http://wisec2017.ccs.neu.edu/travel-grants.html *Important Dates * Application deadline: June 1, 2017 Award notification: June 5, 2017 Deadline to accept/decline the award: June 7, 2017 -- Thanks, Best Regards, Chhagan Lal, PhD --001a11401b7edf35c8054f67491c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Students,

The 10th ACM Confe= rence on Security and Privacy in Wireless and Mobile Networks=C2=A0(ACM WiS= ec 2017) to be held from July 18 to July 20, 2017 in Boston, USA=C2=A0is pl= eased to announce competitive travel grants to attend ACM WiSec 2017=C2=A0(= http:= //wisec2017.ccs.neu.edu/index.html) Conference and all co-located = events such as Poster and Demo sessions. Graduate students with an interest= in the areas of mobile and wireless systems security and are interested in= attending ACM WiSec 2017 are encouraged to apply for a student travel gran= t. The conference will partially subsidize travel costs up to $1,000 of tho= se who would otherwise be unable to attend. More information and applicatio= n instructions are available on the conference website:=C2=A0

http://wisec2017.ccs.neu.edu/travel-grants.html=C2=A0

Important Dates=C2=A0

Application deadline: June 1, 2017=C2=A0
Award notification: Jun= e 5, 2017=C2=A0
Deadline to accept/decline the award: June 7, 201= 7

--
Thanks,
Best Regards,
Chha= gan Lal, PhD
--001a11401b7edf35c8054f67491c-- From nobody Sun May 14 04:53:15 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5012949B; Sun, 14 May 2017 04:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0zsvcCKTdem; Sun, 14 May 2017 04:53:04 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71B112946F; Sun, 14 May 2017 04:51:27 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id y201so76178440qka.0; Sun, 14 May 2017 04:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3LQbzmGblcxMWgM3Gi6Y99BZO3sl9GSz0Et8NfyWy/s=; b=DdIZOoypbUfqnMSjBw9XIcclsdE1PcZTy4bblXaSMbPaoLUQWE3YeYCl0nWuVwvmAe 8/eeo+xEMOcs4tfGz7eqTO76qeEP77T+aYEc7YNIE34YpDpl1B0huF3Ea39++C5t4m9p iUS/IpnrR2W6WnZ1v2ACQZ9kSRFaClNAQ1QJn8Ny/9trOrBCLRe68SGTnSf0+9/y6rxD fl+VAV2LnfCtn4WGMsGTPmZgS5BnjhIgs/uA8CiZl1Ib5W0xVsfpCmDhIrbFrPxFOUnT 3SsOD8MMFoKpJmDeCg3sn56ptveSKHZAMnGxYFyMX+1PxOC7gm3dKosQc1PHtrmpTTjm NZTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3LQbzmGblcxMWgM3Gi6Y99BZO3sl9GSz0Et8NfyWy/s=; b=Xknco8drJhjJwjBE5vZoHQihRmMladwAoEnckej3xu55a/6aeIy5ZdEsADYmt74hqj YQIEbfK9+DEZOAOHw184XtcSb+fpR0KjQ1b8RlHAk/nhwi/5814XNzmcbpmB/j8PMf70 zgwUMSfWPaOhgA2Pp7VoeeORzjhR0M/AzG7fCf+BpS2nRzJLSbOIFcmh5cW4AslScxyg oJDqANpIP2vovZH54Ukq7LlJeob2MooT7sLk11HvqEBt9SRyBmsyQnyFab0214JlHutC 1r63ymY9IAWilD5KZMzQjeHYpswLwmSWezXL/6Zxo2X3m+LfFn3mIRC1N/xWg89qwkoU mrpA== X-Gm-Message-State: AODbwcDMjto3tZq0j+uqD7+lwCBqhl4jZnsengbvR4DifTWQNwYOCxUK ML1Wt5LHfeaSsliG+i4nZD1bmOFE1w== X-Received: by 10.55.26.215 with SMTP id l84mr818850qkh.307.1494762686924; Sun, 14 May 2017 04:51:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.52 with HTTP; Sun, 14 May 2017 04:51:26 -0700 (PDT) In-Reply-To: <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> From: Abdussalam Baryun Date: Sun, 14 May 2017 13:51:26 +0200 Message-ID: To: manet Cc: The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org, Benoit.Parrein@polytech.univ-nantes.fr Content-Type: multipart/alternative; boundary="001a1140cd78fa5323054f7a8ed6" Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 11:53:06 -0000 --001a1140cd78fa5323054f7a8ed6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This protocol can be mixing between reactive and proactive processings which is not stable which is not reliable, see the draft mentions: Routers in the same network may choose either proactive or reactive multipa= th calculation independently according to their computation resources. I think the protocol must only support one calculation for each path, making mixed reactive and proactive per path is not stable. While we know that OLSRv2 is a proactive protocol so if we use source routing as in this protocol it should do only reactive calculation that makes it stable in the dynamic-networks like manet. IMHO, using reactive and proactive independently seems strange in manet routing environment. I advise to look into conditions of its theories because it seems that this multipath routing in for fixed-wireless-networks not for manets. AB On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi wrote: > Dear Suresh, > > Thanks very much for the comments. > Alvaro raised the same issue before =E2=80=94 we will use the type 3 head= er in the > next revision. > > best > > Jiazi > > > > On 10 May 2017, at 04:49, Suresh Krishnan > wrote: > > > > Suresh Krishnan has entered the following ballot position for > > draft-ietf-manet-olsrv2-multipath-12: No Objection > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I find it really strange that this document uses an experimental Routin= g > > header type codepoint (254) but requires the processing to be same as t= he > > RPL Routing header (Type 3). Is there a reason things are done this way > > instead of just using the Type 3 header as is? > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1140cd78fa5323054f7a8ed6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This protocol can be mixing between reactive and proactive processings whic= h is not stable which is not reliable, see the draft mentions:

Routers in the same network may choose either proactive or reactive multipath calculation independen= tly according to their computation resources.
=

<= span style=3D"font-family:courier;font-size:10pt">I think the protocol=C2= =A0must only support one calculation for each=C2=A0path,
making mixed reactive and proactive per path is not stable. W= hile we know that OLSRv2 is a proactive=C2=A0protocol=C2=A0so if we use sou= rce routing as in this protocol it should do only reactive calculation that= makes it stable in the dynamic-networks like manet. IMHO, using reactive a= nd proactive independently seems strange in manet routing environment. I ad= vise to=C2=A0look into conditions of its=C2=A0theories because it seems tha= t this multipath routing in for fixed-wireless-networks not for manets.

AB=


On Wed, May 10, 2017 at 11:29 AM, Jia= zi Yi <ietf@jiaziyi.com> wrote:
Dear Sure= sh,

Thanks very much for the comments.
Alvaro raised the same issue before =E2=80=94 we will use the type 3 header= in the next revision.

best

Jiazi


> On 10 May 2017, at 04:49, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-manet-olsrv2-multipath-12: No Objection
>
>
> -----------= -----------------------------------------------------------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I find it really strange that this document uses an experimental Routi= ng
> header type codepoint (254) but requires the processing to be same as = the
> RPL Routing header (Type 3). Is there a reason things are done this wa= y
> instead of just using the Type 3 header as is?
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet=


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

--001a1140cd78fa5323054f7a8ed6-- From nobody Sun May 14 06:44:21 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2134012773A; Sun, 14 May 2017 06:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puP3JpWeqQd0; Sun, 14 May 2017 06:44:16 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C70E12751F; Sun, 14 May 2017 06:43:19 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id d127so50218106wmf.0; Sun, 14 May 2017 06:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=xw4VPKpq4f0Wnvm+38SxzV5Tepjc6j9Mize0CQrQAGA=; b=aBBUZ/GQdunWxWgbrXDlR9IfRxG5P28Ndxf022EF/UPUWA3ZDrG3UmRoBP7HVmAgmM p2m7GF2Mzvm4NQsIlqW8w9ZfrYZFqmFapYuQQmbtO028ZXAxg2wrTppUaRPEWUEkFC8k 6iRkb4ELqrtdMxqfBCK4JISCtj0dwo4367E0+gPTBFshHhCvAtv3ivhuG5C9CkPtlQ8U h5VpkeHIjWC33fiUlmXfaCUzyf5l2sfZqHXkjNF3L5xwtcHlkNmIENMbETXvbQgqiYTj wgZw/35oAEWlUWSYA+SBSy0jGeC3ZoyMNqdgw3l+eo2t68ydtZf3nnPMP89ige5DytEs QlYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xw4VPKpq4f0Wnvm+38SxzV5Tepjc6j9Mize0CQrQAGA=; b=cEUul1FWvn95sxhlQ7yd9YmpPEnnJFgkILGSPu/doPENLSDd7CbBjFkf/an7+wiRUc WKsJF6bJzFxNAZ/2qHklPIzxSo9b0AEqNfjRqtgYwltW7253/GZPTBugZDNqjDw3ov1G j4/C67OsnZ9ZBYPzo2ohRMzv1YCtd3luzYO8a29JhV5YRliQzXOc+BviNqurlZkgwQ4k RVcqLmzHg2hu6T3HovLgB9iXlNhKrlNttZvS6+kbqValTQCLKdEGN3p9haDMnXrAHFqJ BtJ8ZzQaczSc3EEO0YAzYZmQdfVrM9+M20B0z42Xf7VuFbOn4hI1Lt7Fpb7O2IalFqNC BrFg== X-Gm-Message-State: AODbwcDnddKFvLyN4M2lrBputQNtfTYKDDmsVJXnzGj0ycWmuZmAb8V7 j7uhy2hT/IeOKQ== X-Received: by 10.28.54.165 with SMTP id y37mr1042044wmh.29.1494769397969; Sun, 14 May 2017 06:43:17 -0700 (PDT) Received: from [192.168.1.154] ([213.205.251.252]) by smtp.gmail.com with ESMTPSA id w68sm10911611wrb.49.2017.05.14.06.43.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 May 2017 06:43:17 -0700 (PDT) References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-71CB1547-E5DA-4B57-AF6E-A4FD4C3F04C2 Message-Id: Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org X-Mailer: iPhone Mail (14E304) From: Christopher Dearlove Date: Sun, 14 May 2017 14:43:14 +0100 To: Abdussalam Baryun Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 13:44:19 -0000 --Apple-Mail-71CB1547-E5DA-4B57-AF6E-A4FD4C3F04C2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The reactivity is local, unlike the reactivity of, say, AODV. So while it in= troduces a delay (and possible issues of buffering, and possible effects on,= say, TCP) it does not introduce any routing instability. It's not mixing tw= o ways to calculate a path (which would not be good). (If the calculation is fast enough, you wouldn't even know it had happened.)= (Personally I wouldn't have introduced the reactive complication, but the de= signers/implementers wanted it.) -- =20 Christopher Dearlove christopher.dearlove@gmail.com chris@mnemosyne.demon.co.uk is dead > On 14 May 2017, at 12:51, Abdussalam Baryun w= rote: >=20 > This protocol can be mixing between reactive and proactive processings whi= ch is not stable which is not reliable, see the draft mentions: >=20 > Routers in the same network may choose either proactive or reactive multip= ath calculation independently according to their computation resources. >=20 > I think the protocol must only support one calculation for each path, > making mixed reactive and proactive per path is not stable. While we know t= hat OLSRv2 is a proactive protocol so if we use source routing as in this pr= otocol it should do only reactive calculation that makes it stable in the dy= namic-networks like manet. IMHO, using reactive and proactive independently s= eems strange in manet routing environment. I advise to look into conditions o= f its theories because it seems that this multipath routing in for fixed-wir= eless-networks not for manets. >=20 > AB >=20 >=20 >> On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi wrote: >> Dear Suresh, >>=20 >> Thanks very much for the comments. >> Alvaro raised the same issue before =E2=80=94 we will use the type 3 head= er in the next revision. >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >> > On 10 May 2017, at 04:49, Suresh Krishnan w= rote: >> > >> > Suresh Krishnan has entered the following ballot position for >> > draft-ietf-manet-olsrv2-multipath-12: No Objection >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I find it really strange that this document uses an experimental Routin= g >> > header type codepoint (254) but requires the processing to be same as t= he >> > RPL Routing header (Type 3). Is there a reason things are done this way= >> > instead of just using the Type 3 header as is? >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-71CB1547-E5DA-4B57-AF6E-A4FD4C3F04C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The reactivity is local, unlike the re= activity of, say, AODV. So while it introduces a delay (and possible issues o= f buffering, and possible effects on, say, TCP) it does not introduce any ro= uting instability. It's not mixing two ways to calculate a path (which would= not be good).

(If the calculation is fast enough, you wouldn't even know i= t had happened.)

(Personally I wouldn't have introduced the reactive compli= cation, but the designers/implementers wanted it.)

--  
Chri= stopher Dearlove
On 14 May 2017, at 12:51, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

This protocol can be mixing between reactive and proactive processings which= is not stable which is not reliable, see the draft mentions:

=
Routers in the same network may choose either proactive or reactive multipath calculation independentl= y according to their computation resources.

I think the protocol must o= nly support one calculation for each path,
making mixed reactive and proactive per path is not stable. While we know t= hat OLSRv2 is a proactive protocol so if we use source routing as i= n this protocol it should do only reactive calculation that makes it stable i= n the dynamic-networks like manet. IMHO, using reactive and proactive indepe= ndently seems strange in manet routing environment. I advise to look in= to conditions of its theories because it seems that this multipath rout= ing in for fixed-wireless-networks not for manets.

AB
=

On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi <<= a href=3D"mailto:ietf@jiaziyi.com" target=3D"_blank">ietf@jiaziyi.com>= ; wrote:
Dear Suresh,

Thanks very much for the comments.
Alvaro raised the same issue before =E2=80=94 we will use the type 3 header i= n the next revision.

best

Jiazi


> On 10 May 2017, at 04:49, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-manet-olsrv2-multipath-12: No Objection
>
>
> ------------= ----------------------------------------------------------
> COMMENT:
> -------------------------------------------------------------= ---------
>
> I find it really strange that this document uses an experimental Routin= g
> header type codepoint (254) but requires the processing to be same as t= he
> RPL Routing header (Type 3). Is there a reason things are done this way=
> instead of just using the Type 3 header as is?
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-71CB1547-E5DA-4B57-AF6E-A4FD4C3F04C2-- From nobody Sun May 14 13:55:26 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ED4129A8F; Sun, 14 May 2017 13:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeW5Eh_miaYD; Sun, 14 May 2017 13:55:20 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44471126B6E; Sun, 14 May 2017 13:51:13 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id j17so68810232uag.3; Sun, 14 May 2017 13:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WYjD1TssySIX8pv7THBJ268A7I/vY1BfT2ckj8rLr5c=; b=vbTdXSrW5iy5cLQRehxRitxJWT58eibzsGCChR28Y4avnwMa/B19ZLIR0zzdqLpC2q Y4qYxtbDhpO8G8H9oF7KQSizI36JdqJKmZkgboOI5IoT4c02FwV3w4u9qfzwMHdWCSse /eYfr8MtQ5RtR5N7DdORfT7rDJhqa2QZRqqb/b6xR6oKuTABh37smz3hrBQ1obZP5aKZ /BSFVC0HW5UKMarOfIUYS0hWAn6q7Oyp142Gf17s0Uoy1M6oE5D4WN6Wx2hdGKusPT8o Uw4xaUHxRUmuoH9ZvhQV9OQqIz/mqPi9oCoRYiMS4eA3D9w2UDmyUITwH+0j5URNtypV kndw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WYjD1TssySIX8pv7THBJ268A7I/vY1BfT2ckj8rLr5c=; b=gwdSFkU1hAVAcpCf6j2fjPokV7WrwG3jtKZkQy/5rWjnsJWJndTwWHhh/piKOcS733 vpJ7IDyDNrZtFFtCWLCbaF5WKlDK4gPV6KDH6HvBa52spPMy/sWy9h+FjjrSA/lNRKqn rO0HsapzRWs0A3Frm7xy6JErAWSHTP+OZ3jIu/FboDteoVBo0vzG68f7UtPdnr2ApRjI BFAR7Orxy/s34rPWKL4GxTf9IoyPiCpqDxYR3XSZMAg5WieD8UUk8xaCrZeOJ2FHJ1hR yvglRlIKXQOtcEDq0l61wX1M+b9ulO2I6IUVYy4Vhm+CYyMxEekEPwFYPbMf/96Ap0wM UK5g== X-Gm-Message-State: AODbwcCBo6P2Gg0ane6ueGV3DC+va34K0Xn1OVHxSvQ+jcuX95nIxPlk HdPdpWJaR7XEsff5f7vFMWd4GV0Anmsy X-Received: by 10.176.79.5 with SMTP id n5mr1315077uah.101.1494795072311; Sun, 14 May 2017 13:51:12 -0700 (PDT) MIME-Version: 1.0 References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> In-Reply-To: From: Justin Dean Date: Sun, 14 May 2017 20:51:01 +0000 Message-ID: To: Jiazi Yi , Warren Kumari Cc: The IESG , manet , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group Content-Type: multipart/alternative; boundary="f403043c46844c1540054f8219f1" Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2017 20:55:24 -0000 --f403043c46844c1540054f8219f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think having people directed to the list regarding questions of implimentations is completely appropriate. Justin Dean On Thu, May 11, 2017, 11:45 AM Jiazi Yi wrote: > Hi, > > > > > "Although with existing experience, multiple paths can be obtained even > with such partial information, the calculation might be impacted, > depending on the MPR selection algorithm used." - I don't understand the > "with existing experience", and this sentence is a fragment. I suspect > that removing " with existing experience," would make this cleaner, but I > don't really understand what you are trying to say=E2=80=A6 > > > Does this sound better: > > Although multiple paths can be obtained even with such partial informatio= n > based on existing experience, the calculation might be impacted depending > on > the Multi-Point Relay (MPR) selection algorithm used. > > > I think, "Experience has shown that multiple paths can be obtained > even with such partial information, however, depending on the > Multi-Point Relay (MPR) selection algorithm used, the calculation > might be impacted=E2=80=9D. > > > Yes. > > I'm not quite sure what you mean by: "calculation > might be impacted" - perhaps "suboptimal results may be obtained"? Or > something. > > > It=E2=80=99s the disjointness of the paths calculated. We will clarify it= in the > text also. > > > > 5.1: > "CUTOFF_RATIO The ratio that defines the maximum metric of a path > compared to the shortest path kept in the OLSRv2 Routing Set. For > example, the metric to a destination is R_metric based on the > Routing Set." - I don't understand what the last sentence is trying to > say. > > "CUTOFF_RATIO MUST be greater than or > equal to 1. Note that setting the value to 1 means looking for > equal length paths, which may not be possible in some networks." > -- surely setting it to 2 (or any other number) will also end up > looking for paths which might not be possible? > E.g: > =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94= =80=E2=94=90 > =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1=E2=94= =82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R3=E2= =94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=90 > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2= =94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80= =E2=94=80=E2=94=98 =E2=96=BC > =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94= =80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94= =90 > =E2=94=82 S =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2=94= =82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82 > =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94= =98 > > > Yes. This is intentional: to avoid having too much variance between > multiple > paths obtained. > > > > Yup, but if set to 2, you might also not be able to find a path that > works, so I think you need to remove: "Note that setting the value to > 1 means looking for equal length paths, which may not be possible in > some networks." -- or perhaps, "Setting the number low makes it less > likely that additional paths will be found -- for example, setting it > to 1 will only consider equal length paths" ? (I don't feel strongly > about any of this) > > > Yeah, this would be better. thanks. > > > > > > 9. Configuration Parameters > "the users of this protocol > are also encouraged to explore different parameter setting in various > network environments, and provide feedback." -- where? > > > Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You meant where to= provide the > feedback? There is contact information of the authors in the draft, and > apparently, the mailing list is the right place also. If you want, we can > call it out explicitly in the draft. > > > > Yup, that would be great -- perhaps "and provide feedback to the MANET > WG " > ID Guidlines contains: > > "It is strongly recommended that the draft include a notice (with > email address) of where comments should be sent. For example: > > "Comments are solicited and should be addressed to the working > group's mailing list at ___@______ and/or the author(s)." > " > -- perhaps just copy that. Actually, chairs, do you want this (don't > want to clutter up your list). > > > I=E2=80=99m fine with the proposed text, unless the chairs are explicitly= against > it ;) > > Again, thanks very much for the review and the comments! > > regards > > Jiazi > > > > > > 12. "IANA Considerations > This section adds one new Message TLV, allocated as a new Type > Extension to an existing Message TLV." > -- this section seems to be missing some important information, like > which registry this updates Message Type 7 in. > > > The registry is "Message TLV Types=E2=80=9D specified in > https://tools.ietf.org/html/rfc7631 > We will add related information in the new revision. > > > Win! > > > best > > Jiazi > > > Awesome, thank you for addressing all these... > > W > > > > > > Nits: > S1.1: > > "Because the packet drop is normally bursty in a path" -- "Because packet > drops on a path are normally bursty"... > > "Other than general experiences including the protocol specification and > interoperability with base OLSRv2 implementations, the experiences in the > following aspects are highly appreciated:" > s/ experiences including/ experiences, including / (grammar) > s/ the experiences / experiences / (grammar) > > "Although with existing experience, multiple paths can be obtained even > with such partial information, the calculation might be impacted, > depending on the MPR selection algorithm used." > s/Although with existing experience/Although, with existing experience/ > (grammar) > > "In scenarios where the length of the source routing header is critical, > the loose source routing can be considered." > s/ the loose source / loose source / > > "for example, the paths with lower metrics (i.e., higher quality) can > transfer more datagrams compared to paths with higher metrics." -- nit: > many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you > might want to clarify (or just say packet) > > S3: > "MP-OLSRv2 is designed for networks with dynamic topology by avoiding > single route failure." - this makes it sound like it was *designed* by > avoiding single route failure. > > "in IPv4 networks the interoperability is achieved by using loose source > routing header;" - in IPv4 networks interoperability is achieved using > loose source routing headers;" (or "by using the loose...") > > S4: > "The reactive operation is local in the router" - "local to the router" > > > S5.1: > "All the intermediate routers MUST be included in the source routing > header, which makes the number of hops to be kept a variable." > -- I don't understand how the "the number of hops to be kept" is "a > variable"; this makes it sound like I can set the number of hops to be > kept. Perhaps you meant "a variable number of hops" or "the number of > hops changes"? > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > --f403043c46844c1540054f8219f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think having people directed to the list regarding questio= ns of implimentations is completely appropriate.

Justin Dean


On Thu, May 11, 2017, 11:45= AM Jiazi Yi <ietf@jiaziyi.com&g= t; wrote:
Hi,=C2=A0

<snip>
=


"Although with existing experience, mul= tiple paths can be obtained even
with such partial information, =C2=A0th= e calculation might be impacted,
depending on the MPR selection algorith= m used." - I don't understand the
"with existing experienc= e", and this sentence is a fragment. I suspect
that removing "= with existing experience," would make this cleaner, but I
don'= t really understand what you are trying to say=E2=80=A6


Does thi= s sound better:

Although multiple paths can be obtained even with su= ch partial information
based on existing experience, the calculation mig= ht be impacted depending on
the Multi-Point Relay (MPR) selection algori= thm used.


I think, = "Experience has shown that multiple paths can be obtained
even with such partial information, however, = depending on the
Multi-Point Rela= y (MPR) selection algorithm used, the calculation
might be impacted=E2=80=9D.

=
Yes.=C2=A0
=

I'm not quite sure what you mean by: "calculationmight be impacted" - perhaps "su= boptimal results may be obtained"? Or
something.

It=E2=80=99s the disj= ointness of the paths calculated. We will clarify it in the text also.=C2= =A0

<snip>

5.1:
"CUTOFF_RATIO =C2=A0=C2=A0The ratio that defi= nes the maximum metric of a path
compared to the shortest path kept in t= he OLSRv2 Routing Set. For
example, the metric to a destination is R_met= ric based on the
Routing Set." - I don't understand what the la= st sentence is trying to
say.

"CUTOFF_RATIO MUST be greater = than or
=C2=A0=C2=A0=C2=A0=C2=A0equal to 1.=C2=A0 Note that setting the = value to 1 means looking for
=C2=A0=C2=A0=C2=A0=C2=A0equal length paths,= which may not be possible in some networks."
-- surely setting it = to 2 (or any other number) will also end up
looking for paths which migh= t not be possible?
E.g:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=94=8C= =E2=94=80=E2=94=80=E2=94=90 =C2=A0=E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =C2= =A0=E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =C2=A0=E2=94=8C=E2=94=80=E2=94=80= =E2=94=90
=E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94= =82R1=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2= =94=82R3=E2=94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=90
=E2=94=82 =C2=A0=C2=A0=C2=A0=C2=A0= =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =C2=A0=E2=94=94=E2=94=80=E2=94=80=E2= =94=98 =C2=A0=E2=94=94=E2=94=80=E2=94=80=E2=94=98 =C2=A0=E2=94=94=E2=94=80= =E2=94=80=E2=94=98 =C2=A0=C2=A0=C2=A0=C2=A0=E2=96=BC
=E2=94=8C=E2=94=80= =E2=94=80=E2=94=80=E2=94=90 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=94=8C=E2=94=80=E2=94= =80=E2=94=80=E2=94=90
=E2=94=82 S =E2=94=82=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =96=B6=E2=94=82R6=E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82 D =E2= =94=82
=E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=E2=94=94=E2=94=80=E2=94=80= =E2=94=98 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98


Yes. This is in= tentional: to avoid having too much variance between multiple
paths obta= ined.


Yup, but if set to= 2, you might also not be able to find a path that
works, so I think you need to remove: "Note that set= ting the value to
1 means looking= for equal length paths, which may not be possible in
some networks." -- or perhaps, "Setting the = number low makes it less
likely t= hat additional paths will be found -- for example, setting it
to 1 will only consider equal length paths&quo= t; ? (I don't feel strongly
a= bout any of this)

=
Yeah, this would be bett= er. thanks.=C2=A0

<snip>



9.=C2=A0 Configuration Parameters
&quo= t;the users of this protocol
=C2=A0are also encouraged to explore differ= ent parameter setting in various
network environments, and provide feedb= ack." =C2=A0-- where?


Hmmm=E2=80=A6 I didn=E2=80=99t quite = get the question. You meant where to provide the
feedback? There is cont= act information of the authors in the draft, and
apparently, the mailing= list is the right place also. If you want, we can
call it out explicitl= y in the draft.


Yup, tha= t would be great -- perhaps "and provide feedback to the MANET<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">WG <insert list name>"=
<= span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v= ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star= t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;f= loat:none;display:inline!important">ID Guidlines contains:

"It is strongly recommended that the draft = include a notice (with
=C2=A0=C2= =A0email address) of where comments should be sent.=C2=A0 For example:

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Co= mments are solicited and should be addressed to the working
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0group's mailin= g list at ___@______ and/or the author(s)."
"
-- perhaps= just copy that.=C2=A0 Actually, chairs, do you want this (don't=
<= span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v= ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star= t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;f= loat:none;display:inline!important">want to clutter up your list).

I=E2=80=99m fine with the proposed text, unless th= e chairs are explicitly against it ;)

Again, thank= s very much for the review and the comments!

regar= ds

Jiazi




12. =C2=A0"IANA Considerations
=C2=A0This section adds one= new Message TLV, allocated as a new Type
=C2=A0Extension to an existing= Message TLV."
-- this section seems to be missing some important i= nformation, like
which registry this updates Message Type 7 in.

<= br>The registry is "Message TLV Types=E2=80=9D specified in
https://tools.ie= tf.org/html/rfc7631
We will add related information in the new revis= ion.

Win!


best

Jiazi


Awesome, thank you for addressing all these...

W





Nits= :
S1.1:

"Because the packet drop is normally bursty in a pat= h" -- "Because packet
drops on a path are normally bursty"= ;...

"Other than general experiences including the protocol spe= cification and
interoperability with base OLSRv2 implementations, the ex= periences in the
following aspects are highly appreciated:"
s/ e= xperiences including/ experiences, including / (grammar)
s/ the experien= ces / experiences / (grammar)

"Although with existing experienc= e, =C2=A0multiple paths can be obtained even
with such partial informati= on, =C2=A0the calculation might be impacted,
depending on the MPR select= ion algorithm used."
s/Although with existing experience/Although, = with existing experience/
(grammar)

"In scenarios where the = length of the source routing header is critical,
the loose source routin= g can be considered."
s/ the loose source / =C2=A0loose source /
"for =C2=A0example, the paths with lower metrics (i.e., higher qu= ality) can
transfer more datagrams compared to paths with higher metrics= ." -- nit:
many people (perhaps incorrectly) associate 'datagra= m' with 'UDP' - you
might want to clarify (or just say packe= t)

S3:
"MP-OLSRv2 is designed for networks with dynamic topo= logy by avoiding
single route failure." - this makes it sound like = it was *designed* by
avoiding single route failure.

"in IPv4= networks the interoperability is achieved by using loose source
routing= header;" - in IPv4 networks interoperability is achieved using
loo= se source routing headers;" (or "by using the loose...")
=
S4:
"The reactive operation is local in the router" - &quo= t;local to the router"


S5.1:
"All the intermediate = routers MUST be included in the source routing
header, which makes the n= umber of hops to be kept a variable."
-- I don't understand how= the "the number of hops to be kept" is "a
variable"= ; this makes it sound like I can set the number of hops to be
kept. Perh= aps you meant "a variable number of hops" or "the number of<= br>hops changes"?


_________________________________________= ______
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet





--=C2=A0
I don't think the execution is relevant wh= en it was obviously a bad
idea in= the first place.
This is like pu= tting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid wease= ls and that pair
of pants.=
<= span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v= ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star= t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;f= loat:none;display:inline!important">=C2=A0=C2=A0---maf
--f403043c46844c1540054f8219f1-- From nobody Mon May 15 00:56:17 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA46129B2B; Mon, 15 May 2017 00:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tj8piUM_2eN; Mon, 15 May 2017 00:54:39 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F92E129B16; Mon, 15 May 2017 00:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1494834633; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=10243; bh=/UOQ7HJJf8rMJ2KFQKFCrFS9EwvYZeSkQeRxCtIKIkg=; b=hGnsmge7ThJ13uj7F3oGMnh2q9bVyR8OGvYOCj698GJGRUxw9A3b227YlvXF+Uw2 kVyo8ybKv/tgfRRp+rVq7SR+aMZUHH535Z7LyjBG3wpZCdwMLlzr/KPS2TeQ+O4FRdL XJtUyThFkTF8RsSpsTmsRImgCDH1BsUi8X6Mrslo= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1494834633275233.59540419407404; Mon, 15 May 2017 00:50:33 -0700 (PDT) From: Jiazi Yi Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DEBB08ED-9B4E-4412-80B0-E329FB921EA3" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 15 May 2017 09:50:39 +0200 In-Reply-To: Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group To: Abdussalam Baryun References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 07:54:41 -0000 --Apple-Mail=_DEBB08ED-9B4E-4412-80B0-E329FB921EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi AB,=20 As Chris said, reactive/proactive approach has nothing to do with = stability you mentioned. It=E2=80=99s totally a router=E2=80=99s = internal process =E2=80=94 the outsiders won=E2=80=99t even know the = difference.=20 best Jiazi > On 14 May 2017, at 13:51, Abdussalam Baryun = wrote: >=20 > This protocol can be mixing between reactive and proactive processings = which is not stable which is not reliable, see the draft mentions: >=20 > Routers in the same network may choose either proactive or reactive = multipath calculation independently according to their computation = resources. >=20 > I think the protocol must only support one calculation for each path, > making mixed reactive and proactive per path is not stable. While we = know that OLSRv2 is a proactive protocol so if we use source routing as = in this protocol it should do only reactive calculation that makes it = stable in the dynamic-networks like manet. IMHO, using reactive and = proactive independently seems strange in manet routing environment. I = advise to look into conditions of its theories because it seems that = this multipath routing in for fixed-wireless-networks not for manets. >=20 > AB >=20 >=20 > On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi > wrote: > Dear Suresh, >=20 > Thanks very much for the comments. > Alvaro raised the same issue before =E2=80=94 we will use the type 3 = header in the next revision. >=20 > best >=20 > Jiazi >=20 >=20 > > On 10 May 2017, at 04:49, Suresh Krishnan > wrote: > > > > Suresh Krishnan has entered the following ballot position for > > draft-ietf-manet-olsrv2-multipath-12: No Objection > > > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > I find it really strange that this document uses an experimental = Routing > > header type codepoint (254) but requires the processing to be same = as the > > RPL Routing header (Type 3). Is there a reason things are done this = way > > instead of just using the Type 3 header as is? > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet = >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet = >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_DEBB08ED-9B4E-4412-80B0-E329FB921EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi AB, 

As Chris said, reactive/proactive = approach has nothing to do with stability you mentioned. It=E2=80=99s = totally a router=E2=80=99s internal process =E2=80=94 the outsiders = won=E2=80=99t even know the difference. 

best

Jiazi

On = 14 May 2017, at 13:51, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

This protocol can be mixing between reactive and proactive processings = which is not stable which is not reliable, see the draft mentions:

Routers in the same network may choose either proactive or reactive multipath calculation independently according to their computation resources.

I think the = protocol must only support one calculation for = each path,
making mixed = reactive and proactive per path is not stable. While we know that OLSRv2 = is a proactive protocol so if we use source routing as in this = protocol it should do only reactive calculation that makes it stable in = the dynamic-networks like manet. IMHO, using reactive and proactive = independently seems strange in manet routing environment. I advise = to look into conditions of its theories because it seems that = this multipath routing in for fixed-wireless-networks not for = manets.

AB


On Wed, = May 10, 2017 at 11:29 AM, Jiazi Yi <ietf@jiaziyi.com> wrote:
Dear Suresh,

Thanks very much for the comments.
Alvaro raised the same issue before =E2=80=94 we will use the type 3 = header in the next revision.

best

Jiazi


> On 10 May 2017, at 04:49, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-manet-olsrv2-multipath-12: No = Objection
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I find it really strange that this document uses an experimental = Routing
> header type codepoint (254) but requires the processing to be same = as the
> RPL Routing header (Type 3). Is there a reason things are done this = way
> instead of just using the Type 3 header as is?
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


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

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

= --Apple-Mail=_DEBB08ED-9B4E-4412-80B0-E329FB921EA3-- From nobody Mon May 15 08:14:18 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B44129478 for ; Mon, 15 May 2017 08:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_zqrxWZ7VHD for ; Mon, 15 May 2017 08:14:14 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33223129BA2 for ; Mon, 15 May 2017 08:09:52 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id e55so81395857uaa.2 for ; Mon, 15 May 2017 08:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gEwyPYQcXtQoLaUeXeQ0eLNqNkeo62V61+w7XGMn/O4=; b=N50aMD2e9tom0fpgNIUj0eDM02V3NHLhodwX1OGhDYOZ/9n6SvsbMktic7+xHmL2Cr /+IIIKkIPTu9KQkxiNtGPJdxOJwYaI4zTfeDAxDtdXQ+PcJJVnpRZE8ATxkWffEXyhq+ sbE/J2DuUzmAUj5sIvM88TvkT0sag0lJhKC99XGNlieFxstVI2wlZzZsVQako9amwFNv 5PPPX5SZqxegoDRDUTomxw4uTb7+CPRDyypBCauLAFXLedtzOzRzTqFyc+bBXonmRr2K ZECt4xGIZuPCdFriXRICv69ZYVhjKiRdhDL9G3mgL9VftSff4m86kwWEEWzE8ONQZ9xe NIlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gEwyPYQcXtQoLaUeXeQ0eLNqNkeo62V61+w7XGMn/O4=; b=o80yOtOOPL8XIfNdK0CGF42sjhroXb+bXxfEBv7JMTfANbxUZHrfp6oqHw6D2bI4/q 2pZ1ts+7NjtkCImgwMqL5e0iIMablMp8cxsaUbQ3gUoOsTiSJyTSJV7NB81qEDCHf3Be ytHPAfm7kmWYFWG7nOQ/OeNrOojL33H2u0FdDtHbk+3Irf1rMK18nOBQ8dVV1/njovR2 NvnFtm7UtWoTlVA7C3+ghsCoWnVSiMHjWubk68t36NGOwxjyvc8q3Xr0BuQYaN+iGbrV VodSu0SgWz4fp9BAHhBjYNBJsmp7VULerhDgUCCc0yxJgqn2TMoGm6dRae7KsejPsWWC NOQA== X-Gm-Message-State: AODbwcAkkMxphn00xPiX5VGEaYdhqBooOi1pU8dmFZhT+7ZwQUP5h3Py N0b2T4yBDDEACn8enfja2xCfMr2pRy/P X-Received: by 10.176.23.227 with SMTP id p35mr2671112uaf.155.1494860990881; Mon, 15 May 2017 08:09:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.71.83 with HTTP; Mon, 15 May 2017 08:09:10 -0700 (PDT) In-Reply-To: References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> From: Warren Kumari Date: Mon, 15 May 2017 11:09:10 -0400 Message-ID: To: Justin Dean Cc: Jiazi Yi , The IESG , manet , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 15:14:18 -0000 Great. Thanks all... W On Sun, May 14, 2017 at 4:51 PM, Justin Dean wrote: > I think having people directed to the list regarding questions of > implimentations is completely appropriate. > > Justin Dean > > > On Thu, May 11, 2017, 11:45 AM Jiazi Yi wrote: >> >> Hi, >> >> >> >> >> "Although with existing experience, multiple paths can be obtained even >> with such partial information, the calculation might be impacted, >> depending on the MPR selection algorithm used." - I don't understand the >> "with existing experience", and this sentence is a fragment. I suspect >> that removing " with existing experience," would make this cleaner, but = I >> don't really understand what you are trying to say=E2=80=A6 >> >> >> Does this sound better: >> >> Although multiple paths can be obtained even with such partial informati= on >> based on existing experience, the calculation might be impacted dependin= g >> on >> the Multi-Point Relay (MPR) selection algorithm used. >> >> >> I think, "Experience has shown that multiple paths can be obtained >> even with such partial information, however, depending on the >> Multi-Point Relay (MPR) selection algorithm used, the calculation >> might be impacted=E2=80=9D. >> >> >> Yes. >> >> I'm not quite sure what you mean by: "calculation >> might be impacted" - perhaps "suboptimal results may be obtained"? Or >> something. >> >> >> It=E2=80=99s the disjointness of the paths calculated. We will clarify i= t in the >> text also. >> >> >> >> 5.1: >> "CUTOFF_RATIO The ratio that defines the maximum metric of a path >> compared to the shortest path kept in the OLSRv2 Routing Set. For >> example, the metric to a destination is R_metric based on the >> Routing Set." - I don't understand what the last sentence is trying to >> say. >> >> "CUTOFF_RATIO MUST be greater than or >> equal to 1. Note that setting the value to 1 means looking for >> equal length paths, which may not be possible in some networks." >> -- surely setting it to 2 (or any other number) will also end up >> looking for paths which might not be possible? >> E.g: >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94= =80=E2=94=90 >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1=E2=94= =82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R3=E2= =94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=90 >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80= =E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=96=BC >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94= =80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94= =90 >> =E2=94=82 S =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2=94= =82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82 >> =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94= =98 >> >> >> Yes. This is intentional: to avoid having too much variance between >> multiple >> paths obtained. >> >> >> >> Yup, but if set to 2, you might also not be able to find a path that >> works, so I think you need to remove: "Note that setting the value to >> 1 means looking for equal length paths, which may not be possible in >> some networks." -- or perhaps, "Setting the number low makes it less >> likely that additional paths will be found -- for example, setting it >> to 1 will only consider equal length paths" ? (I don't feel strongly >> about any of this) >> >> >> Yeah, this would be better. thanks. >> >> >> >> >> >> 9. Configuration Parameters >> "the users of this protocol >> are also encouraged to explore different parameter setting in various >> network environments, and provide feedback." -- where? >> >> >> Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You meant where t= o provide the >> feedback? There is contact information of the authors in the draft, and >> apparently, the mailing list is the right place also. If you want, we ca= n >> call it out explicitly in the draft. >> >> >> >> Yup, that would be great -- perhaps "and provide feedback to the MANET >> WG " >> ID Guidlines contains: >> >> "It is strongly recommended that the draft include a notice (with >> email address) of where comments should be sent. For example: >> >> "Comments are solicited and should be addressed to the working >> group's mailing list at ___@______ and/or the author(s)." >> " >> -- perhaps just copy that. Actually, chairs, do you want this (don't >> want to clutter up your list). >> >> >> I=E2=80=99m fine with the proposed text, unless the chairs are explicitl= y against >> it ;) >> >> Again, thanks very much for the review and the comments! >> >> regards >> >> Jiazi >> >> >> >> >> >> 12. "IANA Considerations >> This section adds one new Message TLV, allocated as a new Type >> Extension to an existing Message TLV." >> -- this section seems to be missing some important information, like >> which registry this updates Message Type 7 in. >> >> >> The registry is "Message TLV Types=E2=80=9D specified in >> https://tools.ietf.org/html/rfc7631 >> We will add related information in the new revision. >> >> >> Win! >> >> >> best >> >> Jiazi >> >> >> Awesome, thank you for addressing all these... >> >> W >> >> >> >> >> >> Nits: >> S1.1: >> >> "Because the packet drop is normally bursty in a path" -- "Because packe= t >> drops on a path are normally bursty"... >> >> "Other than general experiences including the protocol specification and >> interoperability with base OLSRv2 implementations, the experiences in th= e >> following aspects are highly appreciated:" >> s/ experiences including/ experiences, including / (grammar) >> s/ the experiences / experiences / (grammar) >> >> "Although with existing experience, multiple paths can be obtained even >> with such partial information, the calculation might be impacted, >> depending on the MPR selection algorithm used." >> s/Although with existing experience/Although, with existing experience/ >> (grammar) >> >> "In scenarios where the length of the source routing header is critical, >> the loose source routing can be considered." >> s/ the loose source / loose source / >> >> "for example, the paths with lower metrics (i.e., higher quality) can >> transfer more datagrams compared to paths with higher metrics." -- nit: >> many people (perhaps incorrectly) associate 'datagram' with 'UDP' - you >> might want to clarify (or just say packet) >> >> S3: >> "MP-OLSRv2 is designed for networks with dynamic topology by avoiding >> single route failure." - this makes it sound like it was *designed* by >> avoiding single route failure. >> >> "in IPv4 networks the interoperability is achieved by using loose source >> routing header;" - in IPv4 networks interoperability is achieved using >> loose source routing headers;" (or "by using the loose...") >> >> S4: >> "The reactive operation is local in the router" - "local to the router" >> >> >> S5.1: >> "All the intermediate routers MUST be included in the source routing >> header, which makes the number of hops to be kept a variable." >> -- I don't understand how the "the number of hops to be kept" is "a >> variable"; this makes it sound like I can set the number of hops to be >> kept. Perhaps you meant "a variable number of hops" or "the number of >> hops changes"? >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed May 17 04:14:26 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8E129479; Wed, 17 May 2017 04:14:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149501966459.6639.7362226295968105924@ietfa.amsl.com> Date: Wed, 17 May 2017 04:14:24 -0700 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 11:14:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Rules for Designing Protocols Using the RFC 5444 Generalized Packet/ Message Format Authors : Thomas Clausen Christopher Dearlove Ulrich Herberg Henning Rogge Filename : draft-ietf-manet-rfc5444-usage-06.txt Pages : 26 Date : 2017-05-17 Abstract: RFC 5444 specifies a generalized MANET packet/message format and describes an intended use for multiplexed MANET routing protocol messages that is mandated to use on the port/protocol specified by RFC 5498. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals, and which would have led to interoperability problems, to the impediment of protocol extension development, and to an inability to use optional generic parsers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-06 https://datatracker.ietf.org/doc/html/draft-ietf-manet-rfc5444-usage-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc5444-usage-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 19 05:20:44 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91E12947B; Fri, 19 May 2017 05:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh43Bwq6JMAF; Fri, 19 May 2017 05:20:38 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C8E128D64; Fri, 19 May 2017 05:14:43 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id f55so56202641qta.3; Fri, 19 May 2017 05:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZM2h/+nmJXLHYvj/HVfvzwFIkE43plliI5Tr9nIe+3w=; b=eqMhEFs/yXdWDIDsk0O3DtWIhxE8qJ3vkjpT3wY15jImsnaooUO8cQtHhqUjTF/88r bTESDwRXYnruu2dVTsxaJ9S9YmgLClvlzgn4NXsmcVSf5svc6bmpEWSXwKfsRjQccfvY 81CSXbv3qaX+bRP067adE9TItlCY4RKAUMqDt9ochCM4Y1nejkYTHcVqeNnSnavPRYDD ZTgYIZnC5oOW9e4IPY0826iduCACMJ3lUty2QXyWTr/jmcmtQgn2Rs8CbYJRqp3bUEbT czX58jPZ1pJNlhdQHf9ES/0ksUYNUWYRk3kNYlXS+v9Bcxb2i6YGPMMm+TjcG55zLGU6 6txg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZM2h/+nmJXLHYvj/HVfvzwFIkE43plliI5Tr9nIe+3w=; b=KcfDTNmdd89+WhMDVmEmIVkmLx89ocupfGPc0SCY7F6z0SiNfFFhXJIWR+u4ezAMZl C1GGdc5sDQLkxCqZr4s+fr+ou5DPQmDbmpr1rYkrxlgmgxk+c/npPfERjv6FdGzVHNIU 2+ATEzThwndow4jGMZ9yzxEd5qcEhXfcm7GgkZFJcOVEhoEoJdWwTn+PKQholhnvZ96W imSG3OZ64SXp8nTA5Z+NiP/RNlrnFFZTdwr0i35uimPBYFdX1+LAsxOnR8pMuca8h4Bg LR5N5CnhQWBbuUX6BhYRIq/R7R8OwnZbLkgxm9VxZnbTmnM7xVhofZYMXfDwhtjslL+Y TIUg== X-Gm-Message-State: AODbwcBvmSHAaLaRyeEm0m5/uiq4TIANKsMk/kxesVkP06yg4Xnzb8OH 5iS0Oe0TLtYvmpuWCgok+CtfRGoFyNpI X-Received: by 10.200.47.83 with SMTP id k19mr9997713qta.254.1495196082341; Fri, 19 May 2017 05:14:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.52 with HTTP; Fri, 19 May 2017 05:14:41 -0700 (PDT) In-Reply-To: References: <149443053917.11242.9983663008416318557.idtracker@ietfa.amsl.com> <6F3176EF-9AC5-44A2-A3C2-DC2E0529CB35@jiaziyi.com> From: Abdussalam Baryun Date: Fri, 19 May 2017 14:14:41 +0200 Message-ID: To: Warren Kumari Cc: Justin Dean , manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group Content-Type: multipart/alternative; boundary="001a1136fa785b90be054fdf77c7" Archived-At: Subject: Re: [manet] Warren Kumari's No Objection on draft-ietf-manet-olsrv2-multipath-13: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 12:20:42 -0000 --001a1136fa785b90be054fdf77c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes it is a good idea to add the list address, but need IESG/wg-chairs work harder to maintain acknowledgements/replies to any participants that send to the list/draft. AB On Mon, May 15, 2017 at 5:09 PM, Warren Kumari wrote: > Great. Thanks all... > > W > > On Sun, May 14, 2017 at 4:51 PM, Justin Dean wrote= : > > I think having people directed to the list regarding questions of > > implimentations is completely appropriate. > > > > Justin Dean > > > > > > On Thu, May 11, 2017, 11:45 AM Jiazi Yi wrote: > >> > >> Hi, > >> > >> > >> > >> > >> "Although with existing experience, multiple paths can be obtained eve= n > >> with such partial information, the calculation might be impacted, > >> depending on the MPR selection algorithm used." - I don't understand t= he > >> "with existing experience", and this sentence is a fragment. I suspect > >> that removing " with existing experience," would make this cleaner, bu= t > I > >> don't really understand what you are trying to say=E2=80=A6 > >> > >> > >> Does this sound better: > >> > >> Although multiple paths can be obtained even with such partial > information > >> based on existing experience, the calculation might be impacted > depending > >> on > >> the Multi-Point Relay (MPR) selection algorithm used. > >> > >> > >> I think, "Experience has shown that multiple paths can be obtained > >> even with such partial information, however, depending on the > >> Multi-Point Relay (MPR) selection algorithm used, the calculation > >> might be impacted=E2=80=9D. > >> > >> > >> Yes. > >> > >> I'm not quite sure what you mean by: "calculation > >> might be impacted" - perhaps "suboptimal results may be obtained"? Or > >> something. > >> > >> > >> It=E2=80=99s the disjointness of the paths calculated. We will clarify= it in the > >> text also. > >> > >> > >> > >> 5.1: > >> "CUTOFF_RATIO The ratio that defines the maximum metric of a path > >> compared to the shortest path kept in the OLSRv2 Routing Set. For > >> example, the metric to a destination is R_metric based on the > >> Routing Set." - I don't understand what the last sentence is trying to > >> say. > >> > >> "CUTOFF_RATIO MUST be greater than or > >> equal to 1. Note that setting the value to 1 means looking for > >> equal length paths, which may not be possible in some networks." > >> -- surely setting it to 2 (or any other number) will also end up > >> looking for paths which might not be possible? > >> E.g: > >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94= =80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2= =94=80=E2=94=90 > >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1=E2= =94=82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R3= =E2=94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=90 > >> =E2=94=82 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80= =E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94= =80=E2=94=80=E2=94=98 =E2=96=BC > >> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90 =E2=94=8C=E2= =94=80=E2=94=80=E2=94=90 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2= =94=90 > >> =E2=94=82 S =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6=E2= =94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82 > >> =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98 =E2=94=94=E2= =94=80=E2=94=80=E2=94=98 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2= =94=98 > >> > >> > >> Yes. This is intentional: to avoid having too much variance between > >> multiple > >> paths obtained. > >> > >> > >> > >> Yup, but if set to 2, you might also not be able to find a path that > >> works, so I think you need to remove: "Note that setting the value to > >> 1 means looking for equal length paths, which may not be possible in > >> some networks." -- or perhaps, "Setting the number low makes it less > >> likely that additional paths will be found -- for example, setting it > >> to 1 will only consider equal length paths" ? (I don't feel strongly > >> about any of this) > >> > >> > >> Yeah, this would be better. thanks. > >> > >> > >> > >> > >> > >> 9. Configuration Parameters > >> "the users of this protocol > >> are also encouraged to explore different parameter setting in various > >> network environments, and provide feedback." -- where? > >> > >> > >> Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You meant where= to provide the > >> feedback? There is contact information of the authors in the draft, an= d > >> apparently, the mailing list is the right place also. If you want, we > can > >> call it out explicitly in the draft. > >> > >> > >> > >> Yup, that would be great -- perhaps "and provide feedback to the MANET > >> WG " > >> ID Guidlines contains: > >> > >> "It is strongly recommended that the draft include a notice (with > >> email address) of where comments should be sent. For example: > >> > >> "Comments are solicited and should be addressed to the working > >> group's mailing list at ___@______ and/or the author(s)." > >> " > >> -- perhaps just copy that. Actually, chairs, do you want this (don't > >> want to clutter up your list). > >> > >> > >> I=E2=80=99m fine with the proposed text, unless the chairs are explici= tly > against > >> it ;) > >> > >> Again, thanks very much for the review and the comments! > >> > >> regards > >> > >> Jiazi > >> > >> > >> > >> > >> > >> 12. "IANA Considerations > >> This section adds one new Message TLV, allocated as a new Type > >> Extension to an existing Message TLV." > >> -- this section seems to be missing some important information, like > >> which registry this updates Message Type 7 in. > >> > >> > >> The registry is "Message TLV Types=E2=80=9D specified in > >> https://tools.ietf.org/html/rfc7631 > >> We will add related information in the new revision. > >> > >> > >> Win! > >> > >> > >> best > >> > >> Jiazi > >> > >> > >> Awesome, thank you for addressing all these... > >> > >> W > >> > >> > >> > >> > >> > >> Nits: > >> S1.1: > >> > >> "Because the packet drop is normally bursty in a path" -- "Because > packet > >> drops on a path are normally bursty"... > >> > >> "Other than general experiences including the protocol specification a= nd > >> interoperability with base OLSRv2 implementations, the experiences in > the > >> following aspects are highly appreciated:" > >> s/ experiences including/ experiences, including / (grammar) > >> s/ the experiences / experiences / (grammar) > >> > >> "Although with existing experience, multiple paths can be obtained ev= en > >> with such partial information, the calculation might be impacted, > >> depending on the MPR selection algorithm used." > >> s/Although with existing experience/Although, with existing experience= / > >> (grammar) > >> > >> "In scenarios where the length of the source routing header is critica= l, > >> the loose source routing can be considered." > >> s/ the loose source / loose source / > >> > >> "for example, the paths with lower metrics (i.e., higher quality) can > >> transfer more datagrams compared to paths with higher metrics." -- nit= : > >> many people (perhaps incorrectly) associate 'datagram' with 'UDP' - yo= u > >> might want to clarify (or just say packet) > >> > >> S3: > >> "MP-OLSRv2 is designed for networks with dynamic topology by avoiding > >> single route failure." - this makes it sound like it was *designed* by > >> avoiding single route failure. > >> > >> "in IPv4 networks the interoperability is achieved by using loose sour= ce > >> routing header;" - in IPv4 networks interoperability is achieved using > >> loose source routing headers;" (or "by using the loose...") > >> > >> S4: > >> "The reactive operation is local in the router" - "local to the router= " > >> > >> > >> S5.1: > >> "All the intermediate routers MUST be included in the source routing > >> header, which makes the number of hops to be kept a variable." > >> -- I don't understand how the "the number of hops to be kept" is "a > >> variable"; this makes it sound like I can set the number of hops to be > >> kept. Perhaps you meant "a variable number of hops" or "the number of > >> hops changes"? > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > >> > >> > >> > >> > >> > >> -- > >> I don't think the execution is relevant when it was obviously a bad > >> idea in the first place. > >> This is like putting rabid weasels in your pants, and later expressing > >> regret at having chosen those particular rabid weasels and that pair > >> of pants. > >> ---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1136fa785b90be054fdf77c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes it is a good idea to add the list address, but=C2= =A0need IESG/wg-chairs work harder to maintain acknowledgements/replies to = any participants that send to the list/draft.

AB

On Mon,= May 15, 2017 at 5:09 PM, Warren Kumari <warren@kumari.net> = wrote:
Great. Thanks all...

W

On Sun, May 14, 2017 at 4:51 PM, Justin Dean <bebemaster@gmail.com> wrote:
> I think having people directed to the list regarding questions of
> implimentations is completely appropriate.
>
> Justin Dean
>
>
> On Thu, May 11, 2017, 11:45 AM Jiazi Yi <ietf@jiaziyi.com> wrote:
>>
>> Hi,
>>
>> <snip>
>>
>>
>> "Although with existing experience, multiple paths can be obt= ained even
>> with such partial information,=C2=A0 the calculation might be impa= cted,
>> depending on the MPR selection algorithm used." - I don't= understand the
>> "with existing experience", and this sentence is a fragm= ent. I suspect
>> that removing " with existing experience," would make th= is cleaner, but I
>> don't really understand what you are trying to say=E2=80=A6 >>
>>
>> Does this sound better:
>>
>> Although multiple paths can be obtained even with such partial inf= ormation
>> based on existing experience, the calculation might be impacted de= pending
>> on
>> the Multi-Point Relay (MPR) selection algorithm used.
>>
>>
>> I think, "Experience has shown that multiple paths can be obt= ained
>> even with such partial information, however, depending on the
>> Multi-Point Relay (MPR) selection algorithm used, the calculation<= br> >> might be impacted=E2=80=9D.
>>
>>
>> Yes.
>>
>> I'm not quite sure what you mean by: "calculation
>> might be impacted" - perhaps "suboptimal results may be = obtained"? Or
>> something.
>>
>>
>> It=E2=80=99s the disjointness of the paths calculated. We will cla= rify it in the
>> text also.
>>
>> <snip>
>>
>> 5.1:
>> "CUTOFF_RATIO=C2=A0 =C2=A0The ratio that defines the maximum = metric of a path
>> compared to the shortest path kept in the OLSRv2 Routing Set. For<= br> >> example, the metric to a destination is R_metric based on the
>> Routing Set." - I don't understand what the last sentence= is trying to
>> say.
>>
>> "CUTOFF_RATIO MUST be greater than or
>>=C2=A0 =C2=A0 =C2=A0equal to 1.=C2=A0 Note that setting the value t= o 1 means looking for
>>=C2=A0 =C2=A0 =C2=A0equal length paths, which may not be possible i= n some networks."
>> -- surely setting it to 2 (or any other number) will also end up >> looking for paths which might not be possible?
>> E.g:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=94=8C=E2=94=80=E2=94=80=E2=94=90=C2= =A0 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90=C2=A0 =E2=94=8C=E2=94=80=E2=94=80= =E2=94=90=C2=A0 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90
>> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R1= =E2=94=82=E2=94=80=E2=96=B6=E2=94=82R2=E2=94=82=E2=94=80=E2=96=B6=E2=94=82R= 3=E2=94=9C=E2=94=80=E2=96=B6=E2=94=82R4=E2=94=82=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=90
>> =E2=94=82=C2=A0 =C2=A0 =C2=A0=E2=94=94=E2=94=80=E2=94=80=E2=94=98= =C2=A0 =E2=94=94=E2=94=80=E2=94=80=E2=94=98=C2=A0 =E2=94=94=E2=94=80=E2=94= =80=E2=94=98=C2=A0 =E2=94=94=E2=94=80=E2=94=80=E2=94=98=C2=A0 =C2=A0 =C2=A0= =E2=96=BC
>> =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =E2=94=8C=E2=94=80=E2=94=80=E2=94=90=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=90
>> =E2=94=82 S =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82R6= =E2=94=82=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=96=B6=E2=94=82 D =E2=94=82
>> =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80=E2=94=98=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=98
>>
>>
>> Yes. This is intentional: to avoid having too much variance betwee= n
>> multiple
>> paths obtained.
>>
>>
>>
>> Yup, but if set to 2, you might also not be able to find a path th= at
>> works, so I think you need to remove: "Note that setting the = value to
>> 1 means looking for equal length paths, which may not be possible = in
>> some networks." -- or perhaps, "Setting the number low m= akes it less
>> likely that additional paths will be found -- for example, setting= it
>> to 1 will only consider equal length paths" ? (I don't fe= el strongly
>> about any of this)
>>
>>
>> Yeah, this would be better. thanks.
>>
>> <snip>
>>
>>
>>
>> 9.=C2=A0 Configuration Parameters
>> "the users of this protocol
>>=C2=A0 are also encouraged to explore different parameter setting i= n various
>> network environments, and provide feedback."=C2=A0 -- where?<= br> >>
>>
>> Hmmm=E2=80=A6 I didn=E2=80=99t quite get the question. You meant w= here to provide the
>> feedback? There is contact information of the authors in the draft= , and
>> apparently, the mailing list is the right place also. If you want,= we can
>> call it out explicitly in the draft.
>>
>>
>>
>> Yup, that would be great -- perhaps "and provide feedback to = the MANET
>> WG <insert list name>"
>> ID Guidlines contains:
>>
>> "It is strongly recommended that the draft include a notice (= with
>>=C2=A0 =C2=A0email address) of where comments should be sent.=C2=A0= For example:
>>
>>=C2=A0 =C2=A0 =C2=A0 "Comments are solicited and should be add= ressed to the working
>>=C2=A0 =C2=A0 =C2=A0 group's mailing list at ___@______ and/or = the author(s)."
>> "
>> -- perhaps just copy that.=C2=A0 Actually, chairs, do you want thi= s (don't
>> want to clutter up your list).
>>
>>
>> I=E2=80=99m fine with the proposed text, unless the chairs are exp= licitly against
>> it ;)
>>
>> Again, thanks very much for the review and the comments!
>>
>> regards
>>
>> Jiazi
>>
>>
>>
>>
>>
>> 12.=C2=A0 "IANA Considerations
>>=C2=A0 This section adds one new Message TLV, allocated as a new Ty= pe
>>=C2=A0 Extension to an existing Message TLV."
>> -- this section seems to be missing some important information, li= ke
>> which registry this updates Message Type 7 in.
>>
>>
>> The registry is "Message TLV Types=E2=80=9D specified in
>> https://tools.ietf.org/html/rfc7631
>> We will add related information in the new revision.
>>
>>
>> Win!
>>
>>
>> best
>>
>> Jiazi
>>
>>
>> Awesome, thank you for addressing all these...
>>
>> W
>>
>>
>>
>>
>>
>> Nits:
>> S1.1:
>>
>> "Because the packet drop is normally bursty in a path" -= - "Because packet
>> drops on a path are normally bursty"...
>>
>> "Other than general experiences including the protocol specif= ication and
>> interoperability with base OLSRv2 implementations, the experiences= in the
>> following aspects are highly appreciated:"
>> s/ experiences including/ experiences, including / (grammar)
>> s/ the experiences / experiences / (grammar)
>>
>> "Although with existing experience,=C2=A0 multiple paths can = be obtained even
>> with such partial information,=C2=A0 the calculation might be impa= cted,
>> depending on the MPR selection algorithm used."
>> s/Although with existing experience/Although, with existing experi= ence/
>> (grammar)
>>
>> "In scenarios where the length of the source routing header i= s critical,
>> the loose source routing can be considered."
>> s/ the loose source /=C2=A0 loose source /
>>
>> "for=C2=A0 example, the paths with lower metrics (i.e., highe= r quality) can
>> transfer more datagrams compared to paths with higher metrics.&quo= t; -- nit:
>> many people (perhaps incorrectly) associate 'datagram' wit= h 'UDP' - you
>> might want to clarify (or just say packet)
>>
>> S3:
>> "MP-OLSRv2 is designed for networks with dynamic topology by = avoiding
>> single route failure." - this makes it sound like it was *des= igned* by
>> avoiding single route failure.
>>
>> "in IPv4 networks the interoperability is achieved by using l= oose source
>> routing header;" - in IPv4 networks interoperability is achie= ved using
>> loose source routing headers;" (or "by using the loose..= .")
>>
>> S4:
>> "The reactive operation is local in the router" - "= local to the router"
>>
>>
>> S5.1:
>> "All the intermediate routers MUST be included in the source = routing
>> header, which makes the number of hops to be kept a variable."= ;
>> -- I don't understand how the "the number of hops to be k= ept" is "a
>> variable"; this makes it sound like I can set the number of h= ops to be
>> kept. Perhaps you meant "a variable number of hops" or &= quot;the number of
>> hops changes"?
>>
>>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet=
>>
>>
>>
>>
>>
>> --
>> I don't think the execution is relevant when it was obviously = a bad
>> idea in the first place.
>> This is like putting rabid weasels in your pants, and later expres= sing
>> regret at having chosen those particular rabid weasels and that pa= ir
>> of pants.
>>=C2=A0 =C2=A0---maf



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

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

--001a1136fa785b90be054fdf77c7-- From nobody Fri May 19 05:48:28 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3283A1293FF; Fri, 19 May 2017 05:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7G1hOjk1YfR8; Fri, 19 May 2017 05:48:16 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1E1127077; Fri, 19 May 2017 05:43:02 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id u75so59591423qka.3; Fri, 19 May 2017 05:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=csnv3TL1t75uo6Vb9TypRVQfamKIMGOtlOb3pceg8x4=; b=J6aE8jOWfTw+mnrpNrd0aOCYExpbi+2dW5zDu5qMU74GokOUUFFPx0tddmPl8300zf pyuksK9jJZed1wuz49423MlIcbC0HrxJGvLHRf4wZ+AejTcXoHg/RWi9/4Za9Rn79ST2 W88IORAzPC3emhsxERVvTLpyk56jbnh34hg4FZrZL4n4slVtpBAGmtHHAR7P9lDefYS4 sTsCq5AmD8jgBHmXYOhA2aS6lafVEKhs7D/xqSOEA+gtDFMB1ja5CjOzm+X+9K4waQ02 2FNHGQM63FhSMCVzgyWqLTv0x/tU6UuWqdvkJtDe/qWUuXoCf/27NSSVvgkPIlSZZJKo vRwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=csnv3TL1t75uo6Vb9TypRVQfamKIMGOtlOb3pceg8x4=; b=PoS6L5mSQxdaSkVvH4F60XDyQhPCfgkVoigJ4wG2w6uWHiArTACzXuK7hvFN5GUjKT b/QYTffoFj8/85+mJUBiY8hy0UkS3FZel1lvd+K4EZvsWeBpJz6jSMu3LHxt4K2mq7rR pS+y1JKK1cGcJf1rPqLeytQEs1yoFEZ7dEEo5ZinTVeYVPGGnqJC2ImBeA6Yqd6FcOMe I1O8Tmvh0Twdy5k+Yh2wLks1hBUKHz746lYMAm1PpaM/y2/kxEBJqLN+L6aaRG7X07Ne QowgjJPWPSeK9pv2gTZqzY4Dfr2efYZ8u7vG2H9i4SbxXJOb/0xFk+y5nq4hWI08WRoe /3Hg== X-Gm-Message-State: AODbwcBzCyaw+donPD1e4/MMoMs7IHAJmuo4cMOYSPI0FqDHLZRAvKiV 6nixHh9+mOojUldQA37ztEf5e51wTz7K X-Received: by 10.55.18.141 with SMTP id 13mr9345658qks.135.1495197781968; Fri, 19 May 2017 05:43:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.52 with HTTP; Fri, 19 May 2017 05:43:01 -0700 (PDT) In-Reply-To: References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> From: Abdussalam Baryun Date: Fri, 19 May 2017 14:43:01 +0200 Message-ID: To: Christopher Dearlove Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group Content-Type: multipart/alternative; boundary="001a11475840a9ccd7054fdfdcf8" Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 12:48:18 -0000 --001a11475840a9ccd7054fdfdcf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What do you mean by local reactive, I did not understand. Is our routing having local and not local, if yes then why don't we say in the draft local reactivity? AB On Sun, May 14, 2017 at 3:43 PM, Christopher Dearlove < christopher.dearlove@gmail.com> wrote: > The reactivity is local, unlike the reactivity of, say, AODV. So while it > introduces a delay (and possible issues of buffering, and possible effect= s > on, say, TCP) it does not introduce any routing instability. It's not > mixing two ways to calculate a path (which would not be good). > > (If the calculation is fast enough, you wouldn't even know it had > happened.) > > (Personally I wouldn't have introduced the reactive complication, but the > designers/implementers wanted it.) > > -- > Christopher Dearlove > christopher.dearlove@gmail.com > chris@mnemosyne.demon.co.uk is dead > > On 14 May 2017, at 12:51, Abdussalam Baryun > wrote: > > This protocol can be mixing between reactive and proactive processings > which is not stable which is not reliable, see the draft mentions: > Routers in the same network may choose either proactive or reactive multi= path > calculation independently according to their computation resources. > > I think the protocol must only support one calculation for each path, > making mixed reactive and proactive per path is not stable. While we know > that OLSRv2 is a proactive protocol so if we use source routing as in thi= s > protocol it should do only reactive calculation that makes it stable in t= he > dynamic-networks like manet. IMHO, using reactive and proactive > independently seems strange in manet routing environment. I advise to loo= k > into conditions of its theories because it seems that this multipath > routing in for fixed-wireless-networks not for manets. > > AB > > > On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi wrote: > >> Dear Suresh, >> >> Thanks very much for the comments. >> Alvaro raised the same issue before =E2=80=94 we will use the type 3 hea= der in >> the next revision. >> >> best >> >> Jiazi >> >> >> > On 10 May 2017, at 04:49, Suresh Krishnan >> wrote: >> > >> > Suresh Krishnan has entered the following ballot position for >> > draft-ietf-manet-olsrv2-multipath-12: No Objection >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I find it really strange that this document uses an experimental Routi= ng >> > header type codepoint (254) but requires the processing to be same as >> the >> > RPL Routing header (Type 3). Is there a reason things are done this wa= y >> > instead of just using the Type 3 header as is? >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11475840a9ccd7054fdfdcf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What do you mean by local reactive, I did not underst= and. Is our routing having local and not local, if yes then why don't w= e say in the draft local reactivity?

AB

On Sun, May 14, = 2017 at 3:43 PM, Christopher Dearlove <christopher.dearlove@g= mail.com> wrote:
The reactivity is local, unlike the reactivity of, say, AODV= . So while it introduces a delay (and possible issues of buffering, and pos= sible effects on, say, TCP) it does not introduce any routing instability. = It's not mixing two ways to calculate a path (which would not be good).=

(If the calculation is fast en= ough, you wouldn't even know it had happened.)

(Personally I wouldn't have introduced the reactive= complication, but the designers/implementers wanted it.)

-- =C2=A0<= span class=3D"HOEnZb">
Christopher Dearlove

On 14 May 2017, at= 12:51, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

<= blockquote type=3D"cite">

This protocol can be mixing between reactive and proactive processings whic= h is not stable which is not reliable, see the draft mentions:

Routers in the same network may choose either proactive or reactive multipath calculation independen= tly according to their computation resources.
=

<= span style=3D"font-family:courier;font-size:10pt">I think the protocol=C2= =A0must only support one calculation for each=C2=A0path,
making mixed reactive and proactive per path is not stable. W= hile we know that OLSRv2 is a proactive=C2=A0protocol=C2=A0so if we use sou= rce routing as in this protocol it should do only reactive calculation that= makes it stable in the dynamic-networks like manet. IMHO, using reactive a= nd proactive independently seems strange in manet routing environment. I ad= vise to=C2=A0look into conditions of its=C2=A0theories because it seems tha= t this multipath routing in for fixed-wireless-networks not for manets.

AB=


On Wed, May 10, 2017 at 11:29 AM, Jia= zi Yi <ietf@jiaziyi.com> wrote:
Dear Sure= sh,

Thanks very much for the comments.
Alvaro raised the same issue before =E2=80=94 we will use the type 3 header= in the next revision.

best
<= br> Jiazi


> On 10 May 2017, at 04:49, Suresh Krishnan <suresh.krishnan@gmail.com> wr= ote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-manet-olsrv2-multipath-12: No Objection
>
>
> ---------------------------------------= -------------------------------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I find it really strange that this document uses an experimental Routi= ng
> header type codepoint (254) but requires the processing to be same as = the
> RPL Routing header (Type 3). Is there a reason things are done this wa= y
> instead of just using the Type 3 header as is?
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet=


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

___________________= ____________________________
manet mailing list=
manet@ietf.or= g
https://www.ietf.org/mailman/listinfo/manet

--001a11475840a9ccd7054fdfdcf8-- From nobody Fri May 19 05:52:35 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F60D12E058; Fri, 19 May 2017 05:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Xi3N5vvwGk; Fri, 19 May 2017 05:52:32 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B8C12E855; Fri, 19 May 2017 05:46:39 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id f55so56833409qta.3; Fri, 19 May 2017 05:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lBcKovzUteCfwB9TnDKI+pVgEYen7H+hMTcuwp6zjJo=; b=qXhzvo+2nDbQAxRyLkZCk7CUY8gp6D5qMfC/atyqsvZIdBNi/7EKONyBUNwUWS3sDd kT1QRNZCikfyrtBnqqwsvo/Ny8Oi2IU9XCjiSj29JB0JHlzi9Ir0An2IBkP1JRgcatNp x3329QdASTTVB8TbZQQLPnmVVm0bKrDR5ueNyWTngmsplx9GK95D+Gae5e1aP0yVuIcz TUkRJHZ3/Saw02vvEXJ+iKv64p0QBTdXMKQr8b6W52x5OiEcFuCm4Vc4h8s66cfWTuxn lfrktvy1bWbHBQJ5v6NSCwjXz9MkdgAfX24ujco/o6JoOkNfbDCkSlNzZBfmR7xcPjIv ODvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lBcKovzUteCfwB9TnDKI+pVgEYen7H+hMTcuwp6zjJo=; b=Roxue8S91dqbEZEAaHClIvdPaMsP055wTGTEGwh588p92AkdS3Lpzex+JG9chqwV0W NDeWC+HeymUVRTcX1+HLuHiiIJc8737IUSahRc8Fjex2FkICwbXI+xapwmtWmwTsQecG 6dA8X59BGw6bsYEsUZs2VXuAzOqr0TIhXtIqrXIuy5s7CkHfrfMecaihzpbNNJpU/0tV A7llj5HzLgwBSHEF/iek7SfwzaW26hs2/IhPG48qMzGUf3/5jNuUQos5J5LvKs3BKt2x 7hHBeBCs+H2GXxEEuW1I6TbKelO8kLa8/g/NGMF7z9FnXtjsF3E4t09HE8JaOu1OdgL/ 6IVA== X-Gm-Message-State: AODbwcAaEeSBPwe9YBuc7T3frOBMh9KeeeoUc7WcX4AEhinHyApbWKUE Y7R7i4tjy5d8I61OisybWfUE3xYgRXWV X-Received: by 10.237.37.81 with SMTP id w17mr9757989qtc.8.1495197998770; Fri, 19 May 2017 05:46:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.52 with HTTP; Fri, 19 May 2017 05:46:38 -0700 (PDT) In-Reply-To: References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> From: Abdussalam Baryun Date: Fri, 19 May 2017 14:46:38 +0200 Message-ID: To: Jiazi Yi Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, Mobile Ad-hoc Networks Working Group Content-Type: multipart/alternative; boundary="001a1141099e95f0ba054fdfe923" Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 12:52:34 -0000 --001a1141099e95f0ba054fdfe923 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jiazi, Routing processes are in all routers (do you mean other than that?), so what you mean by internal, do you mean there is routing process outside the router???, or as you may mean external process from routers. I think all processes happen in the routers. I am sorry that I got confused,,,, AB On Mon, May 15, 2017 at 9:50 AM, Jiazi Yi wrote: > Hi AB, > > As Chris said, reactive/proactive approach has nothing to do with > stability you mentioned. It=E2=80=99s totally a router=E2=80=99s internal= process =E2=80=94 the > outsiders won=E2=80=99t even know the difference. > > best > > Jiazi > > On 14 May 2017, at 13:51, Abdussalam Baryun > wrote: > > This protocol can be mixing between reactive and proactive processings > which is not stable which is not reliable, see the draft mentions: > Routers in the same network may choose either proactive or reactive multi= path > calculation independently according to their computation resources. > > I think the protocol must only support one calculation for each path, > making mixed reactive and proactive per path is not stable. While we know > that OLSRv2 is a proactive protocol so if we use source routing as in thi= s > protocol it should do only reactive calculation that makes it stable in t= he > dynamic-networks like manet. IMHO, using reactive and proactive > independently seems strange in manet routing environment. I advise to loo= k > into conditions of its theories because it seems that this multipath > routing in for fixed-wireless-networks not for manets. > > AB > > > On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi wrote: > >> Dear Suresh, >> >> Thanks very much for the comments. >> Alvaro raised the same issue before =E2=80=94 we will use the type 3 hea= der in >> the next revision. >> >> best >> >> Jiazi >> >> >> > On 10 May 2017, at 04:49, Suresh Krishnan >> wrote: >> > >> > Suresh Krishnan has entered the following ballot position for >> > draft-ietf-manet-olsrv2-multipath-12: No Objection >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I find it really strange that this document uses an experimental Routi= ng >> > header type codepoint (254) but requires the processing to be same as >> the >> > RPL Routing header (Type 3). Is there a reason things are done this wa= y >> > instead of just using the Type 3 header as is? >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --001a1141099e95f0ba054fdfe923 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jiazi,

Routing processes = are in all=C2=A0 routers (do you mean other than that?), so what you mean b= y internal, do you mean there is routing process outside the router???,=C2= =A0or as you may=C2=A0mean external process from routers. I think all proce= sses happen in the routers. I am sorry that I got confused,,,,
AB

On Mon, May 15, 2017 at 9:50 AM, Jiazi Yi <<= a href=3D"mailto:ietf@jiaziyi.com" target=3D"_blank">ietf@jiaziyi.com&g= t; wrote:
Hi AB,=C2=A0

As Chris said,= reactive/proactive approach has nothing to do with stability you mentioned= . It=E2=80=99s totally a router=E2=80=99s internal process =E2=80=94 the ou= tsiders won=E2=80=99t even know the difference.=C2=A0

<= div>best

Jiazi

On 14 May 2017, at 13:51, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:

This protocol can be mixing between reactive and proactive processings whic= h is not stable which is not reliable, see the draft mentions:

Routers in the same network may choose either proactive or reactive multipath calculation independently according to their computation resources.

I th= ink the protocol=C2=A0must only support one calculation for each=C2=A0path,=
making mixed reactive and proactive per path is not stable. = While we know that OLSRv2 is a proactive=C2=A0protocol=C2=A0so if we use so= urce routing as in this protocol it should do only reactive calculation tha= t makes it stable in the dynamic-networks like manet. IMHO, using reactive = and proactive independently seems strange in manet routing environment. I a= dvise to=C2=A0look into conditions of its=C2=A0theories because it seems th= at this multipath routing in for fixed-wireless-networks not for manets.

AB


On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi <ietf@jiaziyi.com> wrote:
Dear Suresh,

Thanks very much for the comments.
Alvaro raised the same issue before =E2=80=94 we will use the type 3 header= in the next revision.

best
Jiazi


> On 10 May 2017, at 04:49, Suresh Krishnan <suresh.krishnan@gmail.com> wr= ote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-manet-olsrv2-multipath-12: No Objection
>
>
> -----------------------------------------= -----------------------------
> COMMENT:
> ------------------------------------------------------------= ----------
>
> I find it really strange that this document uses an experimental Routi= ng
> header type codepoint (254) but requires the processing to be same as = the
> RPL Routing header (Type 3). Is there a reason things are done this wa= y
> instead of just using the Type 3 header as is?
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet=


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

_______________________________________________
manet mailing list<= br>manet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet


--001a1141099e95f0ba054fdfe923-- From nobody Mon May 22 00:28:58 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A084A12922E; Mon, 22 May 2017 00:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.681 X-Spam-Level: X-Spam-Status: No, score=0.681 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ1se0bknoQi; Mon, 22 May 2017 00:28:54 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C23128B4E; Mon, 22 May 2017 00:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1495438132; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=13871; bh=jSYMwVb8rK3QTBN+MrTkESJJ8CNxOitV2zrSs9MFw4w=; b=XgTpdi3wyn5+XEtQugAmMxGalU/iDNdJyGSz8Ha/bjxm2monKJFRqTcpgrKZlu5p gAuyRK+mgckn6Zcy22smCoBHQ8QSdiOKzSSUpk6M27LKrPERgAAIaMQPnAiLojBkcuA vImADgMObp/mz2OjEeV/5T5teNQTvRz3ONX5wank= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1495438132175786.4148022627138; Mon, 22 May 2017 00:28:52 -0700 (PDT) From: Jiazi Yi Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_97502D35-672A-4AB0-B2E2-7D9EE27CCCA0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 22 May 2017 09:28:49 +0200 In-Reply-To: Cc: manet , Mobile Ad-hoc Networks Working Group To: Abdussalam Baryun References: <149438454593.28420.3155308625575149497.idtracker@ietfa.amsl.com> <0A715A18-8D1D-4759-8AD9-4CC2A8D238EB@jiaziyi.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] Suresh Krishnan's No Objection on draft-ietf-manet-olsrv2-multipath-12: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 07:28:57 -0000 --Apple-Mail=_97502D35-672A-4AB0-B2E2-7D9EE27CCCA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi AB,=20 I think we have already made it clear in the draft: > The reactive operation is local to the router and no additional = routing control messages exchange is required.=20 best Jiazi > On 19 May 2017, at 14:46, Abdussalam Baryun = wrote: >=20 > Hi Jiazi, >=20 > Routing processes are in all routers (do you mean other than that?), = so what you mean by internal, do you mean there is routing process = outside the router???, or as you may mean external process from routers. = I think all processes happen in the routers. I am sorry that I got = confused,,,, >=20 > AB >=20 > On Mon, May 15, 2017 at 9:50 AM, Jiazi Yi > wrote: > Hi AB,=20 >=20 > As Chris said, reactive/proactive approach has nothing to do with = stability you mentioned. It=E2=80=99s totally a router=E2=80=99s = internal process =E2=80=94 the outsiders won=E2=80=99t even know the = difference.=20 >=20 > best >=20 > Jiazi >=20 >> On 14 May 2017, at 13:51, Abdussalam Baryun = > wrote: >>=20 >> This protocol can be mixing between reactive and proactive = processings which is not stable which is not reliable, see the draft = mentions: >>=20 >> Routers in the same network may choose either proactive or reactive = multipath calculation independently according to their computation = resources. >>=20 >> I think the protocol must only support one calculation for each path, >> making mixed reactive and proactive per path is not stable. While we = know that OLSRv2 is a proactive protocol so if we use source routing as = in this protocol it should do only reactive calculation that makes it = stable in the dynamic-networks like manet. IMHO, using reactive and = proactive independently seems strange in manet routing environment. I = advise to look into conditions of its theories because it seems that = this multipath routing in for fixed-wireless-networks not for manets. >>=20 >> AB >>=20 >>=20 >> On Wed, May 10, 2017 at 11:29 AM, Jiazi Yi > wrote: >> Dear Suresh, >>=20 >> Thanks very much for the comments. >> Alvaro raised the same issue before =E2=80=94 we will use the type 3 = header in the next revision. >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >> > On 10 May 2017, at 04:49, Suresh Krishnan = > wrote: >> > >> > Suresh Krishnan has entered the following ballot position for >> > draft-ietf-manet-olsrv2-multipath-12: No Objection >> > >> > >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> > >> > I find it really strange that this document uses an experimental = Routing >> > header type codepoint (254) but requires the processing to be same = as the >> > RPL Routing header (Type 3). Is there a reason things are done this = way >> > instead of just using the Type 3 header as is? >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet = >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet = >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet = >=20 >=20 --Apple-Mail=_97502D35-672A-4AB0-B2E2-7D9EE27CCCA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi AB, 

I think we have already made it clear = in the draft:

The = reactive operation is local to the router and no additional routing = control messages exchange is = required. 


best

Jiazi

On 19 May 2017, at 14:46, Abdussalam Baryun = <abdussalambaryun@gmail.com> wrote:

Hi Jiazi,

Routing processes are in all  = routers (do you mean other than that?), so what you mean by internal, do = you mean there is routing process outside the router???, or as you = may mean external process from routers. I think all processes = happen in the routers. I am sorry that I got confused,,,,

AB

On Mon, = May 15, 2017 at 9:50 AM, Jiazi Yi <ietf@jiaziyi.com> wrote:
Hi = AB, 

As = Chris said, reactive/proactive approach has nothing to do with stability = you mentioned. It=E2=80=99s totally a router=E2=80=99s internal process = =E2=80=94 the outsiders won=E2=80=99t even know the = difference. 

best

Jiazi

On 14 May 2017, at 13:51, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

This protocol can be mixing between reactive and proactive processings = which is not stable which is not reliable, see the draft mentions:

Routers in the same network may choose either proactive or reactive multipath calculation independently according to their computation resources.

I think the = protocol must only support one calculation for = each path,
making mixed = reactive and proactive per path is not stable. While we know that OLSRv2 = is a proactive protocol so if we use source routing as in this = protocol it should do only reactive calculation that makes it stable in = the dynamic-networks like manet. IMHO, using reactive and proactive = independently seems strange in manet routing environment. I advise = to look into conditions of its theories because it seems that = this multipath routing in for fixed-wireless-networks not for = manets.

AB


On Wed, = May 10, 2017 at 11:29 AM, Jiazi Yi <ietf@jiaziyi.com> wrote:
Dear Suresh,

Thanks very much for the comments.
Alvaro raised the same issue before =E2=80=94 we will use the type 3 = header in the next revision.

best

Jiazi


> On 10 May 2017, at 04:49, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-manet-olsrv2-multipath-12: No = Objection
>
>
> = ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I find it really strange that this document uses an experimental = Routing
> header type codepoint (254) but requires the processing to be same = as the
> RPL Routing header (Type 3). Is there a reason things are done this = way
> instead of just using the Type 3 header as is?
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


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

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



= --Apple-Mail=_97502D35-672A-4AB0-B2E2-7D9EE27CCCA0-- From nobody Mon May 22 00:37:01 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CAC128D19; Mon, 22 May 2017 00:36:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149543861290.18049.11521676178502311038@ietfa.amsl.com> Date: Mon, 22 May 2017 00:36:52 -0700 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-14.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 07:36:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Multipath Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-14.txt Pages : 25 Date : 2017-05-22 Abstract: This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-14 https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 22 00:46:53 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01681289C3; Mon, 22 May 2017 00:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXarlLUjbamg; Mon, 22 May 2017 00:46:49 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CB8129B81; Mon, 22 May 2017 00:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1495439206; s=jiazi; d=jiaziyi.com; i=jiazi@jiaziyi.com; h=From:Content-Type:Mime-Version:Subject:Message-Id:References:To:Date; l=10322; bh=anrAJJ8K9q9tltuEP/3MfoRqecdtpL99ffRZraSDZlo=; b=Z2Ks7z9rv6n2InpLnYwaCALLTdTh1gyXuF+LDHwEjjy40HocEzh/rwGXS/wYpHyW /M7ARDYBvupowjtJcePtR7nG4v7+Ld+Z4mjYBd63xotcfLS8pwBxN6ys32sCsha7ZaO V/MjQ9CKb0plQdsE3uXDSkZd8A3hMzUxu3bCipgg= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1495439205901217.31547673803334; Mon, 22 May 2017 00:46:45 -0700 (PDT) From: Jiazi Yi Content-Type: multipart/alternative; boundary="Apple-Mail=_D480D1BC-E8E2-438F-AEE7-2F24711BF591" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5669BBBD-9B1A-4E90-AA18-C97557E4C872@jiaziyi.com> References: <149543861311.18049.4380480678927798097.idtracker@ietfa.amsl.com> To: manet , The IESG , Mirja Kuehlewind , "Alvaro Retana (aretana)" Date: Mon, 22 May 2017 09:46:43 +0200 X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-multipath-14.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 07:46:51 -0000 --Apple-Mail=_D480D1BC-E8E2-438F-AEE7-2F24711BF591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all,=20 We just submitted a new revision of the manet-olsrv2-multipath draft.=20 This revision is based on the comments from the IESG and Chris.=20 Currently, there is one =E2=80=9Cdiscuss=E2=80=9D from Mirja = (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ballot= / = ). A reply has been provided at = https://www.ietf.org/mail-archive/web/manet/current/msg19428.html = Thanks very much for the review and all the comments provided. Further = feedback is welcome.=20 best Jiazi > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-manet-olsrv2-multipath-14.txt > Date: 22 May 2017 at 09:36:53 GMT+2 > To: , "Jiazi Yi" , "Benoit = Parrein" , "Benoit Parrein" = >=20 >=20 > A new version of I-D, draft-ietf-manet-olsrv2-multipath-14.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. >=20 > Name: draft-ietf-manet-olsrv2-multipath > Revision: 14 > Title: Multipath Extension for the Optimized Link State = Routing Protocol version 2 (OLSRv2) > Document date: 2017-05-22 > Group: manet > Pages: 25 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-multipath-14.= txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-14 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-14= > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-14 >=20 > Abstract: > This document specifies a multipath extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the > characteristics of MANETs, especially the dynamic network topology, > using multiple paths can increase aggregated throughput and improve > the reliability by avoiding single route failures. The > interoperability with OLSRv2 is retained. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_D480D1BC-E8E2-438F-AEE7-2F24711BF591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear all, 

We just submitted a new revision of the = manet-olsrv2-multipath draft. 
This revision = is based on the comments from the IESG and Chris. 

Currently, there is one = =E2=80=9Cdiscuss=E2=80=9D from Mirja (https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multip= ath/ballot/). A reply has been provided at https://www.ietf.org/mail-archive/web/manet/current/msg19428.ht= ml

Thanks = very much for the review and all the comments provided. Further feedback = is welcome. 

best

Jiazi


Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-manet-olsrv2-multipath-14.txt
Date: = 22 May 2017 at 09:36:53 = GMT+2
To: = <manet-chairs@ietf.org>, "Jiazi Yi" <jiazi@jiaziyi.com>, = "Benoit Parrein" <benoit.parrein@polytech.univ-nantes.fr>, "Benoit = Parrein" <Benoit.Parrein@polytech.univ-nantes.fr>

A new version of I-D, = draft-ietf-manet-olsrv2-multipath-14.txt
has been = successfully submitted by Jiazi Yi and posted to the
IETF = repository.

Name: = draft-ietf-manet-olsrv2-multipath
Revision: 14
Title:= = Multipath Extension for the Optimized Link State Routing Protocol = version 2 (OLSRv2)
Document date: = 2017-05-22
Group: manet
Pages: 25
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-mu= ltipath-14.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multip= ath/
Htmlized:       https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-1= 4
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-m= ultipath-14
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mul= tipath-14

Abstract:
=   This document specifies a multipath extension for the = Optimized Link
  State Routing Protocol version = 2 (OLSRv2) to discover multiple
  disjoint = paths for Mobile Ad Hoc Networks (MANETs).  Considering the
  characteristics of MANETs, especially the = dynamic network topology,
  using multiple = paths can increase aggregated throughput and improve
=   the reliability by avoiding single route failures. =  The
  interoperability with OLSRv2 is = retained.




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

The IETF = Secretariat


= --Apple-Mail=_D480D1BC-E8E2-438F-AEE7-2F24711BF591-- From nobody Mon May 22 03:44:14 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C53129BDB for ; Mon, 22 May 2017 03:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7cV5gHjdq-T for ; Mon, 22 May 2017 03:44:09 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C3C126CD8 for ; Mon, 22 May 2017 03:44:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=df2bYe3LinU4HJIwlcwLAfqf+JlD5k3AhXfH7y2jJwX6B5oXUzVExrl9A6c8wKOAmzNOHHBFTEnqIgrEFCbSx1sCC4yt2iZj5+eo0LtQDdBAu1qjaJcvaqj8cOK1mT1zay5rYnuILE3AMT4olhxBnUVPTRqtLzOMykPw8Rw6sSg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 29699 invoked from network); 22 May 2017 12:17:26 +0200 Received: from pd9e110d0.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.16.208) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 22 May 2017 12:17:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> Date: Mon, 22 May 2017 12:17:25 +0200 Cc: The IESG , manet@ietf.org, draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> To: Jiazi Yi X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170522101726.28667.34109@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 10:44:12 -0000 Hi Jiazi, sorry for my very late reply. Please see below. > Am 10.05.2017 um 00:51 schrieb Jiazi Yi : >=20 > Dear Mirja,=20 >=20 > Thanks very much for your review and comments. Please find the reply = inline:=20 >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> The following text in section 4 seems to indicate that scheduling is = done >> on a per-packet basis: >> "When there is a >> datagram to be sent to a destination, the source router acquires a >> path from the Multi-path Routing Set (MAY be Round-Robin, or other >> scheduling algorithms)." >> This seems not appropriate as e.g. TCP packets routed on links with >> largely different delays may suffer performance. ECMP usually hashes = the >> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and = routes >> all packets belonging to the same flow on the same route. I recommend = to >> apply the same here. >>=20 >> Also related is this text in section 8.4 that should explain = Round-Robin >> on a per flow basis instead. Further this should only be an example >> scheduling alogirthm while text belong seems to assume that = Round-Robin >> is always used. >> "If a matching Multi-path Routing Tuple is obtained, the Path Tuples >> of the Multi-path Routing Tuple are applied to the datagrams using >> Round-robin scheduling. For example, there are 2 path Tuples >> (Path-1, Path-2) for destination router D. A series of datagrams >> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. >> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 for >> Packet 3, etc. Other path scheduling mechanisms are also possible >> and will not impact the interoperability of different >> implementations.=E2=80=9D >=20 > In fact, the per-packet scheduling is an intentional choice because: >=20 > 1. The aimed scenario is mobile ad hoc networks, which have high = packet loss by nature. One of the most important reasons is route = failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the = packets in disjoint paths (not necessarily equal cost), we can still = make use partial information of the flow, or even reconstruct the flow = with erasure coding. This is especially interesting for video/audio = streaming.=20 This is only true for unreliable or partially reliable traffic. I see = your use case. However, will if you have TCP traffic, you can probably = assume that the traffic is reliable and should not route on a per-packet = basis. This case is not covered in your draft. Also for other non-TCP = you often might not know much about the traffic characteristics and = therefore cannot know if per-packet scheduling is good or bad. Therefore = default should be per-flow. >=20 > 2. In such kind of lossy networks, the traditional TCP performs very = poor [1]. So as far as I know, TCP is not very popular in ad hoc = networks. On the other hand, based on our study, the multi-path routing = can actually reduce the overall jitter [2].=20 I didn=E2=80=99t have time to read the whole paper but on a brief look, = it looks like you take the delay into account for TCP traffic. Which is = what I said above: either you have two links which have more or less the = same delay or re-ordering will be wrongly interpreted as congestion. The = other problem is TCP reduces its sending rate due to loss. So if both = links are congested and losses occurred (in a non-synchronized way), TCP = will react to both signals and reduce its sending rate more than = necessary. That's why I would recommend to schedule TCP as well as other = reliable and congestion-controlled traffic on a per-flow base. Further = for UDP traffic there is no good way to actually know if the traffic is = reliably transmitted and congestion control, so it=E2=80=99s hard to = make such a decision in the network in a general case. >=20 > We understand your concern on this issue (and you can imagine that you = are not the first one who raises this ;). It is also something that we = want to have further experience from this *experimental* draft, as we = stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: >=20 > =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics.=20 > =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath routing, = especially variable latencies. Although current experiment results show = that multipath routing can reduce the jitter in dynamic scenarios, some = transport protocols or applications may be sensitive to the datagram = re-ordering.=20 > =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged. That=E2=80=99s fine but then you cannot assume in the rest of the = document that per-packet scheduling is used. There are two options to handle this: either you remove the text that is = cited above and do not talk about scheduling at all other than in the = experimentation part, or you explain carefully when potentially = per-packet scheduling could be used and make clear that by default and = especially for TCP per-flow scheduling should be used. >=20 >=20 > [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf=20 > [2] Multipath optimized link state routing for mobile ad hoc = networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, = 2011. >=20 >>=20 >> Related is this text in section 8.4.: >> "If datagrams without source routing header need to be forwarded = using >> multiple paths (for example, based on the information of DiffServ >> Code Point [RFC2474])" >> RFC2474 does not specify any application requirements on multipath = use >> and as such the DiffServe field should not be used to determine if = the >> flow can be routed on multiple paths. The ability to profit from >> multipath routing depends not only on the application and protocols = used >> but also on the characteristics of the multipath link(s); so it's = hard to >> make any implicit assumptions here. However, if routing would only be >> recommended on a per-flow basis this problem does not occur and the >> brackets above could be remove. Further, if routed on a per flow = basis >> would be done, DiffServ could actually be used to decide which path = to >> use, if e.g. one path has a lower delay, but that seem to need = further >> discussion as well. >=20 > As we mentioned before, the multipath routing has special interests in = audio/video streaming applications. For applications that requires = strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.=20 Which DiffServ codepoints are you taking about? Some of the code points = require low delay but they either say nothing about reordering or = require a bounded jitter as well which mean forwarding on a per-packet = basis over two links which highly different delays should not be done. Mirja >=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Minor comments/questions: >>=20 >> 1) section 8.4: this sentence is not clear: >> "It is RECOMMENDED to use MTU sizes considering the source routing >> header to avoid fragmentation." >> MAYBE >> "It is NOT RECOMMENDED to fragment the IP packet if the packet with = the >> source routing header would exceed the minimum MTU along the path. = In >> this case source routing and therefore the additional path calculated = by >> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D >=20 > Fixed.=20 >=20 >>=20 >> 2) section 9: >> "For IPv6 networks, it MUST >> be set to 0, i.e., no constraint on maximum number of hops." >> Why is that? >=20 > Because the current RFC6554 supports only IPv6 strict source routing, = we thus need to keep all the path information in the source routing = header, in which case we don=E2=80=99t know the number of hops.=20 >=20 > On the other hand, we noticed that the IPv6 segment routing header is = being discussed at 6man, we thus have the following text in the = =E2=80=9CExperiments to be conducted=E2=80=9D section: >=20 > =E2=80=A2 Use of IPv6 loose source routing. In the current = specification, only strict source routing is used for IPv6 based on = [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routi= ng=E2=80=91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header is = critical, the loose source routing can be considered. >=20 >>=20 >> 3) Not sure why section 12.1. is there? Can this be removed? >=20 > Removed.=20 >=20 > Agains, we appreciate your valuable comments and hope that our reply = addresses your concern.=20 >=20 > regards >=20 > Jiazi >=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From nobody Mon May 22 05:20:18 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4966E129C66 for ; Mon, 22 May 2017 05:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.704 X-Spam-Level: X-Spam-Status: No, score=0.704 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5n2nRgmR8aa for ; Mon, 22 May 2017 05:20:15 -0700 (PDT) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3FE1293FD for ; Mon, 22 May 2017 05:20:15 -0700 (PDT) Received: by mail-lf0-x242.google.com with SMTP id h4so5329097lfj.3 for ; Mon, 22 May 2017 05:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Mf7h1yIGkSohp6SEZu21aJgwOYQgIpa5yWV4f8wG/Mc=; b=KGaPiBcXNWetD2RY/o3BvQUw9BgoPp5eVFnnvXAe8tyV/gPeIaSKEy0diidsgkyHQK Th4R0HSJoDikL03yiwP+t95tmA5U8mCe1X1bXgag7IFO+tVQbq9R8CsEQ3t9B99HdDoz HguhXKNMC5Sen/cnP8u+j6HeJ8HBZGitMfHN4CP6bUolenOFvilJzjEWbzgA1j6gh8gv JtQB0zvJ7iWXyQvpyJ22kihFOamKjExWtnseqygsOc5CravcRcXHjMwG57R8ReTGvJya GMuzPKpHUMyGfRnox4Rhu8AO1uLR7gVKp/uj7FZaGaO4Y7WRbIfYKTJ89+CATCCoqfBm DhAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Mf7h1yIGkSohp6SEZu21aJgwOYQgIpa5yWV4f8wG/Mc=; b=o78a2CQWIFTvdZ2ZBdJFpgH80BLlY//VYiNvljm/4LuzEpYvY+PgaMDmr/Erty0xH7 HzahsPD9KpLUgxDuFe0na4mmuqg6WvVOZ0s9R/boPr2AAwUdKkqGPsuzfYU4SKF/5gZ1 4M/Fli8grMHyYoI6S2GXHDMsXbAG0BE8sNPIv2iX7ERD7QOHfeQCdz1G6Mo/9/BtaFYu gbkpkpQF+0sCy7rd1GfOi5tJWS/Eo/sGarxXMz8+AzJzjjhg3MRk//dnwI7IDKtzNUbS 1/FqMW30HpUfTqedN7x0TD2WQzcu0tZr0nvhaGr7obrkcw0YDYTS33XmHWFH17T+BwKq 8Alg== X-Gm-Message-State: AODbwcANr0nT04hgdg+6hw4+DdnZjin5ZwP8HwfgdRDH9ZMribzjoxqU X+IbgIg+4FzDCXW6fUvUWjg0jheH3Q== X-Received: by 10.46.9.22 with SMTP id 22mr6639110ljj.42.1495455613297; Mon, 22 May 2017 05:20:13 -0700 (PDT) Received: from 52669349336 named unknown by gmailapi.google.com with HTTPREST; Mon, 22 May 2017 14:20:12 +0200 MIME-Version: 1.0 Sender: chhagan.iiita@gmail.com From: chhagan.iiita@gmail.com Date: Mon, 22 May 2017 14:20:12 +0200 X-Google-Sender-Auth: ScY1_BS81hJA-S2vE43Tup9jqTI Message-ID: To: manet@ietf.org Content-Type: multipart/alternative; boundary="001a114b18ba9baa2e05501be4d9" Archived-At: Subject: [manet] =?utf-8?q?=5BWiSec=E2=80=9917=5D_Call_for_Student_Travel_?= =?utf-8?q?Grant_Applications?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 12:20:17 -0000 --001a114b18ba9baa2e05501be4d9 Content-Type: text/plain; charset="UTF-8" Dear Students, The 10th ACM Conference on Security and Privacy in Wireless and Mobile Networks (ACM WiSec 2017) to be held from July 18 to July 20, 2017 in Boston, USA is pleased to announce competitive travel grants to attend ACM WiSec 2017 (http://wisec2017.ccs.neu.edu/index.html) Conference and all co-located events such as Poster and Demo sessions. Graduate students with an interest in the areas of mobile and wireless systems security and are interested in attending ACM WiSec 2017 are encouraged to apply for a student travel grant. The conference will partially subsidize travel costs up to $1,000 of those who would otherwise be unable to attend. More information and application instructions are available on the conference website: http://wisec2017.ccs.neu.edu/travel-grants.html *Important Dates * Application deadline: June 1, 2017 Award notification: June 5, 2017 Deadline to accept/decline the award: June 7, 2017 -- Thanks, Best Regards, Chhagan Lal, PhD --001a114b18ba9baa2e05501be4d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Students,

The 10th ACM Confe= rence on Security and Privacy in Wireless and Mobile Networks=C2=A0(ACM WiS= ec 2017) to be held from July 18 to July 20, 2017 in Boston, USA=C2=A0is pl= eased to announce competitive travel grants to attend ACM WiSec 2017=C2=A0(= http:= //wisec2017.ccs.neu.edu/index.html) Conference and all co-located = events such as Poster and Demo sessions. Graduate students with an interest= in the areas of mobile and wireless systems security and are interested in= attending ACM WiSec 2017 are encouraged to apply for a student travel gran= t. The conference will partially subsidize travel costs up to $1,000 of tho= se who would otherwise be unable to attend. More information and applicatio= n instructions are available on the conference website:=C2=A0

http://wisec2017.ccs.neu.edu/travel-grants.html=C2=A0

Important Dates=C2=A0

Application deadline: June 1, 2017=C2=A0
Award notification: Jun= e 5, 2017=C2=A0
Deadline to accept/decline the award: June 7, 201= 7

--
Thanks,
Best Regards,
Chha= gan Lal, PhD
--001a114b18ba9baa2e05501be4d9-- From nobody Tue May 23 04:49:55 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CC3129AEB; Tue, 23 May 2017 04:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oVcdZRFyJvf; Tue, 23 May 2017 04:49:45 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DF7129A8E; Tue, 23 May 2017 04:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1495540178; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=42437; bh=/OELhmqdejO1L87aK5lKGrsI1I4TuBu1nBKKy1e5W74=; b=DYXkIoXRKFN3W7TOdWwB5J5w42HfsTojvdozGVOYdYpxImowDS2Xf0/lSYfNCIgt RwIfB8DdsGqYlSXJdeU126IJxQYWkUyv1n0FVUQDLBWKeVzp7x9YByU9kxL4rHXiJx3 vBv5yac3v25oecdKKas67XhBV9iALpQP5p2pwfn0= Received: from [129.104.74.24] (129.104.74.24 [129.104.74.24]) by mx.zohomail.com with SMTPS id 1495540178506448.1788070341885; Tue, 23 May 2017 04:49:38 -0700 (PDT) From: Jiazi Yi Message-Id: <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9DF5609C-033B-43E1-82BE-DA06B2D73FBF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 23 May 2017 13:49:35 +0200 In-Reply-To: Cc: The IESG , manet , draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org To: "Mirja Kuehlewind (IETF)" References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 11:49:48 -0000 --Apple-Mail=_9DF5609C-033B-43E1-82BE-DA06B2D73FBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Mirja,=20 Thank very much for your reply.=20 We understand your concern on the performance, especially the issue of = packet reordering when the multipath protocol is applied to transport = protocol like TCP. Therefore, we propose to have some guidelines to = indicate when per-flow scheduling is recommended, and when per-packet = scheduling is recommended.=20 More specifically, in the draft, we propose the text: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In section 1.1, Experiments to be conducted: =E2=80=A2 Different path-selection schedulers. Depending on the = application type and transport layer type either per-flow scheduler or = per-datagram scheduler is applied. By default, round-robin scheduling is = used to select a path to be used. In some scenarios, weighted scheduling = can be considered: for example, the paths with lower metrics (i.e., = higher quality) can transfer more datagrams or flows compared to paths = with higher metrics. In section 8.4, Datagram Processing at the MP-OLSRv2 Originator If a matching Multipath Routing Tuple is obtained, the Path Tuples of = the Multipath Routing Tuple are applied to the datagrams using = round-robin scheduling. The scheduling policy can be either per-flow or = per-datagram, depending on the transport layer protocol and the = application used:=20 - In per-flow scheduling, the datagrams of the same flow is = transmitted through the same path. Different flows are assigned to = different paths according to round-robin scheduling. For example, there = are 2 path Tuples (Path-1, Path-2) for the destination router D. A = series of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to = router D. Path-1 is then chosen for Flow-1, Path-2 for Flow-2, Path-1 = for Flow 3, etc.=20 - In per-datagram scheduling, different datagrams are = transmitted through different paths according to round-robin scheduling. = For example, there are 2 path Tuples (Path-1, Path-2) for the = destination router D. A series of datagrams (Packet-1, Packet-2, = Packet-3, ... etc.) are to be sent to router D. Path-1 is then chosen = for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc.=20 Per-flow scheduling is recommended for transport layer protocols that = require strict ordering of the datagrams such as TCP. By default, = per-flow scheduling is used. Per-Datagram scheduling is recommended for = transport layer protocols that have less constraint on datagram arriving = order such as UDP. In lossy networks, per-datagram scheduling is also = recommended. =20 Other path scheduling mechanisms are also possible and will not impact = the interoperability of different implementations. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If it looks good for you, we will make the modification in the next = revision of the draft.=20 regards Jiazi > On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Jiazi, >=20 > sorry for my very late reply. Please see below. >=20 >> Am 10.05.2017 um 00:51 schrieb Jiazi Yi : >>=20 >> Dear Mirja,=20 >>=20 >> Thanks very much for your review and comments. Please find the reply = inline:=20 >>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> The following text in section 4 seems to indicate that scheduling is = done >>> on a per-packet basis: >>> "When there is a >>> datagram to be sent to a destination, the source router acquires a >>> path from the Multi-path Routing Set (MAY be Round-Robin, or other >>> scheduling algorithms)." >>> This seems not appropriate as e.g. TCP packets routed on links with >>> largely different delays may suffer performance. ECMP usually hashes = the >>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and = routes >>> all packets belonging to the same flow on the same route. I = recommend to >>> apply the same here. >>>=20 >>> Also related is this text in section 8.4 that should explain = Round-Robin >>> on a per flow basis instead. Further this should only be an example >>> scheduling alogirthm while text belong seems to assume that = Round-Robin >>> is always used. >>> "If a matching Multi-path Routing Tuple is obtained, the Path Tuples >>> of the Multi-path Routing Tuple are applied to the datagrams using >>> Round-robin scheduling. For example, there are 2 path Tuples >>> (Path-1, Path-2) for destination router D. A series of datagrams >>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. >>> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 for >>> Packet 3, etc. Other path scheduling mechanisms are also possible >>> and will not impact the interoperability of different >>> implementations.=E2=80=9D >>=20 >> In fact, the per-packet scheduling is an intentional choice because: >>=20 >> 1. The aimed scenario is mobile ad hoc networks, which have high = packet loss by nature. One of the most important reasons is route = failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the = packets in disjoint paths (not necessarily equal cost), we can still = make use partial information of the flow, or even reconstruct the flow = with erasure coding. This is especially interesting for video/audio = streaming.=20 >=20 > This is only true for unreliable or partially reliable traffic. I see = your use case. However, will if you have TCP traffic, you can probably = assume that the traffic is reliable and should not route on a per-packet = basis. This case is not covered in your draft. Also for other non-TCP = you often might not know much about the traffic characteristics and = therefore cannot know if per-packet scheduling is good or bad. Therefore = default should be per-flow. >=20 >>=20 >> 2. In such kind of lossy networks, the traditional TCP performs very = poor [1]. So as far as I know, TCP is not very popular in ad hoc = networks. On the other hand, based on our study, the multi-path routing = can actually reduce the overall jitter [2].=20 >=20 > I didn=E2=80=99t have time to read the whole paper but on a brief = look, it looks like you take the delay into account for TCP traffic. = Which is what I said above: either you have two links which have more or = less the same delay or re-ordering will be wrongly interpreted as = congestion. The other problem is TCP reduces its sending rate due to = loss. So if both links are congested and losses occurred (in a = non-synchronized way), TCP will react to both signals and reduce its = sending rate more than necessary. That's why I would recommend to = schedule TCP as well as other reliable and congestion-controlled traffic = on a per-flow base. Further for UDP traffic there is no good way to = actually know if the traffic is reliably transmitted and congestion = control, so it=E2=80=99s hard to make such a decision in the network in = a general case. >=20 >>=20 >> We understand your concern on this issue (and you can imagine that = you are not the first one who raises this ;). It is also something that = we want to have further experience from this *experimental* draft, as we = stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: >>=20 >> =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics.=20 >> =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath routing, = especially variable latencies. Although current experiment results show = that multipath routing can reduce the jitter in dynamic scenarios, some = transport protocols or applications may be sensitive to the datagram = re-ordering.=20 >> =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged. >=20 > That=E2=80=99s fine but then you cannot assume in the rest of the = document that per-packet scheduling is used. >=20 > There are two options to handle this: either you remove the text that = is cited above and do not talk about scheduling at all other than in the = experimentation part, or you explain carefully when potentially = per-packet scheduling could be used and make clear that by default and = especially for TCP per-flow scheduling should be used. >=20 >=20 >>=20 >>=20 >> [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf=20 >> [2] Multipath optimized link state routing for mobile ad hoc = networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, = 2011. >>=20 >>>=20 >>> Related is this text in section 8.4.: >>> "If datagrams without source routing header need to be forwarded = using >>> multiple paths (for example, based on the information of DiffServ >>> Code Point [RFC2474])" >>> RFC2474 does not specify any application requirements on multipath = use >>> and as such the DiffServe field should not be used to determine if = the >>> flow can be routed on multiple paths. The ability to profit from >>> multipath routing depends not only on the application and protocols = used >>> but also on the characteristics of the multipath link(s); so it's = hard to >>> make any implicit assumptions here. However, if routing would only = be >>> recommended on a per-flow basis this problem does not occur and the >>> brackets above could be remove. Further, if routed on a per flow = basis >>> would be done, DiffServ could actually be used to decide which path = to >>> use, if e.g. one path has a lower delay, but that seem to need = further >>> discussion as well. >>=20 >> As we mentioned before, the multipath routing has special interests = in audio/video streaming applications. For applications that requires = strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.=20 >=20 > Which DiffServ codepoints are you taking about? Some of the code = points require low delay but they either say nothing about reordering or = require a bounded jitter as well which mean forwarding on a per-packet = basis over two links which highly different delays should not be done. >=20 > Mirja >=20 >=20 >>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Minor comments/questions: >>>=20 >>> 1) section 8.4: this sentence is not clear: >>> "It is RECOMMENDED to use MTU sizes considering the source routing >>> header to avoid fragmentation." >>> MAYBE >>> "It is NOT RECOMMENDED to fragment the IP packet if the packet with = the >>> source routing header would exceed the minimum MTU along the path. = In >>> this case source routing and therefore the additional path = calculated by >>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D >>=20 >> Fixed.=20 >>=20 >>>=20 >>> 2) section 9: >>> "For IPv6 networks, it MUST >>> be set to 0, i.e., no constraint on maximum number of hops." >>> Why is that? >>=20 >> Because the current RFC6554 supports only IPv6 strict source routing, = we thus need to keep all the path information in the source routing = header, in which case we don=E2=80=99t know the number of hops.=20 >>=20 >> On the other hand, we noticed that the IPv6 segment routing header is = being discussed at 6man, we thus have the following text in the = =E2=80=9CExperiments to be conducted=E2=80=9D section: >>=20 >> =E2=80=A2 Use of IPv6 loose source routing. In the current = specification, only strict source routing is used for IPv6 based on = [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routi= ng=E2=80=91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header is = critical, the loose source routing can be considered. >>=20 >>>=20 >>> 3) Not sure why section 12.1. is there? Can this be removed? >>=20 >> Removed.=20 >>=20 >> Agains, we appreciate your valuable comments and hope that our reply = addresses your concern.=20 >>=20 >> regards >>=20 >> Jiazi >>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_9DF5609C-033B-43E1-82BE-DA06B2D73FBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Mirja, 

Thank very much for your = reply. 

We = understand your concern on the performance, especially the issue of = packet reordering when the multipath protocol is applied to transport = protocol like TCP. Therefore, we propose to have some guidelines to = indicate when per-flow scheduling is recommended, and when per-packet = scheduling is recommended. 

More specifically, in the draft, we = propose the text:


=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
In section 1.1, Experiments to be = conducted:

=E2=80=A2 Different = path-selection schedulers. Depending on the application type and = transport layer type either per-flow scheduler or per-datagram scheduler = is applied. By default, round-robin scheduling is used to select a path = to be used. In some scenarios, weighted scheduling can be = considered: for example, the paths with lower metrics (i.e., higher = quality) can transfer more datagrams or flows compared to paths = with higher metrics.


In section 8.4, Datagram Processing at the MP-OLSRv2 = Originator

If a matching Multipath Routing Tuple is obtained, the Path = Tuples of the Multipath Routing Tuple are applied to the datagrams = using round-robin scheduling. The scheduling policy can be either = per-flow or per-datagram, depending on the transport layer protocol and = the application used: 

= - In per-flow scheduling, the datagrams of the same flow is = transmitted through the same path. Different flows are assigned to = different paths according to round-robin scheduling. For example, there = are 2 path Tuples (Path-1, Path-2) for the destination router D. A = series of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to = router D. Path-1 is then chosen for Flow-1, Path-2 for Flow-2, = Path-1 for Flow 3, etc. 

- In per-datagram scheduling, = different datagrams are transmitted through different paths according to = round-robin scheduling. For example, there are 2 path Tuples (Path-1, = Path-2) for the destination router D. A series of datagrams = (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent to router = D. Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 = for Packet 3, etc. 

Per-flow scheduling is recommended for transport layer = protocols that require strict ordering of the datagrams such as TCP. By = default, per-flow scheduling is used. Per-Datagram scheduling is = recommended for transport layer protocols that have less constraint on = datagram arriving order such as UDP. In lossy networks, per-datagram = scheduling is also recommended.  
Other path = scheduling mechanisms are also possible and will not impact the = interoperability of different implementations.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If it looks good for = you, we will make the modification in the next revision of the = draft. 

regards

Jiazi



On 22 May 2017, at 12:17, Mirja = Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:

Hi Jiazi,
sorry for my very late reply. Please see = below.

Am 10.05.2017 um 00:51 = schrieb Jiazi Yi <ietf@jiaziyi.com>:

Dear = Mirja, 

Thanks very much for your review and comments. = Please find the reply inline: 

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

The following text in section 4 = seems to indicate that scheduling is done
on a per-packet = basis:
"When there is a
 datagram to be = sent to a destination, the source router acquires a
 path from the Multi-path Routing Set (MAY be = Round-Robin, or other
 scheduling algorithms)."
This seems not appropriate as e.g. TCP packets routed on = links with
largely different delays may suffer = performance. ECMP usually hashes the
5-tuple or 6-tuple = (incl. DiffServ Codepoint) to setup state and routes
all = packets belonging to the same flow on the same route. I recommend to
apply the same here.

Also = related is this text in section 8.4 that should explain Round-Robin
on a per flow basis instead. Further this should only be an = example
scheduling alogirthm while text belong seems to = assume that Round-Robin
is always used.
"If = a matching Multi-path Routing Tuple is obtained, the Path Tuples
 of the Multi-path Routing Tuple are applied to the = datagrams using
 Round-robin scheduling.  For = example, there are 2 path Tuples
 (Path-1, Path-2) = for destination router D. A series of datagrams
 (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent = router D.
 Path-1 is then chosen for Packet-1, Path-2 = for Packet-2, Path-1 for
 Packet 3, etc.  Other = path scheduling mechanisms are also possible
 and = will not impact the interoperability of different
 implementations.=E2=80=9D

In fact, the per-packet scheduling is an intentional choice = because:

1. The aimed scenario is mobile ad = hoc networks, which have high packet loss by nature. One of the most = important reasons is route failure due to mobility =E2=80=94 in such = case, if a per-flow scheduling is applied, the whole flow will lost. On = the other hand, if we send the packets in disjoint paths (not = necessarily equal cost), we can still make use partial information of = the flow, or even reconstruct the flow with erasure coding. This is = especially interesting for video/audio streaming. 

This is only true for unreliable or = partially reliable traffic. I see your use case. However, will if you = have TCP traffic, you can probably assume that the traffic is reliable = and should not route on a per-packet basis. This case is not covered in = your draft. Also for other non-TCP you often might not know much about = the traffic characteristics and therefore cannot know if per-packet = scheduling is good or bad. Therefore default should be = per-flow.


2. In such = kind of lossy networks, the traditional TCP performs very poor [1]. So = as far as I know, TCP is not very popular in ad hoc networks. On the = other hand, based on our study, the multi-path routing can actually = reduce the overall jitter [2]. 

I didn=E2=80=99t have time to read the = whole paper but on a brief look, it looks like you take the delay into = account for TCP traffic. Which is what I said above: either you have two = links which have more or less the same delay or re-ordering will be = wrongly interpreted as congestion. The other problem is TCP reduces its = sending rate due to loss. So if both links are congested and losses = occurred (in a non-synchronized way), TCP will react to both signals and = reduce its sending rate more than necessary. That's why I would = recommend to schedule TCP as well as other reliable and = congestion-controlled traffic on a per-flow base. Further for UDP = traffic there is no good way to actually know if the traffic is reliably = transmitted and congestion control, so it=E2=80=99s hard to make such a = decision in the network in a general case.


We understand = your concern on this issue (and you can imagine that you are not the = first one who raises this ;). It is also something that we want to have = further experience from this *experimental* draft, as we stated in the = =E2=80=9Cexperiments to be conducted=E2=80=9D section:

= =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics. 
=E2=80=A2 = The impacts of the delay variation due to multipath routing. [RFC2991] = brings out some concerns of multipath routing, especially variable = latencies. Although current experiment results show that multipath = routing can reduce the jitter in dynamic scenarios, some transport = protocols or applications may be sensitive to the datagram = re-ordering. 
= =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged.

That=E2=80=99s fine but then you cannot = assume in the rest of the document that per-packet scheduling is = used.

There are two options to handle = this: either you remove the text that is cited above and do not talk = about scheduling at all other than in the experimentation part, or you = explain carefully when potentially per-packet scheduling could be used = and make clear that by default and especially for TCP per-flow = scheduling should be used.



[1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf 
[2] = Multipath optimized link state routing for mobile ad hoc networks", In = Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, 2011.


Related is this text in section 8.4.:
"If = datagrams without source routing header need to be forwarded using
 multiple paths (for example, based on the information = of DiffServ
 Code Point [RFC2474])"
RFC2474 does not specify any application requirements on = multipath use
and as such the DiffServe field should not = be used to determine if the
flow can be routed on multiple = paths. The ability to profit from
multipath routing = depends not only on the application and protocols used
but = also on the characteristics of the multipath link(s); so it's hard to
make any implicit assumptions here. However, if routing would = only be
recommended on a per-flow basis this problem does = not occur and the
brackets above could be remove. Further, = if routed on a per flow basis
would be done, DiffServ = could actually be used to decide which path to
use, if = e.g. one path has a lower delay, but that seem to need further
discussion as well.

As we mentioned before, the multipath routing has special = interests in audio/video streaming applications. For applications that = requires strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information. 

Which DiffServ codepoints are you taking = about? Some of the code points require low delay but they either say = nothing about reordering or require a bounded jitter as well which mean = forwarding on a per-packet basis over two links which highly different = delays should not be done.

Mirja




---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Minor comments/questions:

1) section 8.4: this sentence is not clear:
"It is RECOMMENDED to use MTU sizes considering the source = routing
 header to avoid fragmentation."
MAYBE
"It is NOT RECOMMENDED to fragment the IP = packet if the packet with the
source routing header would =  exceed the minimum MTU along the path. In
this case = source routing and therefore the additional path calculated by
MP-OLSRv2 SHOULD NOT be used.=E2=80=9D

Fixed. 


2) = section 9:
"For IPv6 networks, it MUST
    be set to 0, i.e., no constraint on = maximum number of hops."
Why is that?

Because the current RFC6554 = supports only IPv6 strict source routing, we thus need to keep all the = path information in the source routing header, in which case we don=E2=80=99= t know the number of hops. 

On the other hand, we noticed that the IPv6 segment routing = header is being discussed at 6man, we thus have the following text in = the =E2=80=9CExperiments to be conducted=E2=80=9D section:

=E2=80=A2 Use of IPv6 loose = source routing. In the current specification, only strict source routing = is used for IPv6 based on [RFC6554]. In = [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routing=E2=80=91hea= der], the use of loose source routing is also proposed in IPv6. In = scenarios where the length of the source routing header is critical, the = loose source routing can be considered.


3) Not = sure why section 12.1. is there? Can this be removed?

Removed. 

Agains, we appreciate your valuable comments and hope that = our reply addresses your concern. 

regards

Jiazi



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

= --Apple-Mail=_9DF5609C-033B-43E1-82BE-DA06B2D73FBF-- From nobody Tue May 23 05:12:04 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E7F129B0A for ; Tue, 23 May 2017 05:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9VNUeC0_HM9 for ; Tue, 23 May 2017 05:12:01 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C7D129AF7 for ; Tue, 23 May 2017 05:12:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=bhDAbFX0z3cqGZ8f+pjNYFU9JPPWBODUrqEGl+qzbF6prgZmLxgpR1kmRbvRSWwadddCxTP44UMfAgckAAlZLycE414OEzlQUb4v4bjdK3WrnpT9c5W70bgP3BDvjBDPeSw0q7F7KNXNFecQjkMiwVphOa2qd1TKNidYqI+AArI=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 15419 invoked from network); 23 May 2017 14:11:58 +0200 Received: from p5dec2002.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.32.2) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 23 May 2017 14:11:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> Date: Tue, 23 May 2017 14:10:11 +0200 Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> To: Jiazi Yi X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170523121158.15411.81438@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 12:12:03 -0000 Hi Jiazi, unfortunately, the following sentence is not correct, as basically any = transport can be encapsulated over UDP: > Per-Datagram scheduling is recommended for transport layer protocols = that have less constraint on datagram arriving order such as UDP. I would propose the following sentence: > Per-Datagram scheduling is only recommended if it is known that the = traffic is not sensitive to reordering, e.g. for non-reliable = transmission of media traffic. In this case I would further recommend to add the following sentence: > Note that the use of paths with highly different delays can still have = a negative impact on these kind of transmissions, as packets that arrive = too late may be ignored and therefore have been transmitted = unnecessarily. Further I also don=E2=80=99t agree to this sentence: > In lossy networks, per-datagram scheduling is also recommended. Even in lossy networks, per-datagram scheduling is still not recommended = for TCP (if the delay of the different paths are too diverse). Finally, I would further recommend you to not say that round-robin needs = to be used in section 8.4. I also don=E2=80=99t think you need to have = the two bullet points that explain what per-datagram and per-flow means. = It=E2=80=99s enough to say that per-flow scheduling means that a = decision is made on the first packet which path to use and all = subsequent packets of the same flow (e.g. identified by the 5- or = 6-tuple) need to use the same path. Further please also check section 4 as this also makes assumptions on = the path selection. Thanks, Mirja =20 > Am 23.05.2017 um 13:49 schrieb Jiazi Yi : >=20 > Dear Mirja,=20 >=20 > Thank very much for your reply.=20 >=20 > We understand your concern on the performance, especially the issue of = packet reordering when the multipath protocol is applied to transport = protocol like TCP. Therefore, we propose to have some guidelines to = indicate when per-flow scheduling is recommended, and when per-packet = scheduling is recommended.=20 >=20 > More specifically, in the draft, we propose the text: >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In section 1.1, Experiments to be conducted: >=20 > =E2=80=A2 Different path-selection schedulers. Depending on the = application type and transport layer type either per-flow scheduler or = per-datagram scheduler is applied. By default, round-robin scheduling is = used to select a path to be used. In some scenarios, weighted scheduling = can be considered: for example, the paths with lower metrics (i.e., = higher quality) can transfer more datagrams or flows compared to paths = with higher metrics. >=20 >=20 > In section 8.4, Datagram Processing at the MP-OLSRv2 Originator >=20 > If a matching Multipath Routing Tuple is obtained, the Path Tuples of = the Multipath Routing Tuple are applied to the datagrams using = round-robin scheduling. The scheduling policy can be either per-flow or = per-datagram, depending on the transport layer protocol and the = application used:=20 >=20 > - In per-flow scheduling, the datagrams of the same flow is = transmitted through the same path. Different flows are assigned to = different paths according to round-robin scheduling. For example, there = are 2 path Tuples (Path-1, Path-2) for the destination router D. A = series of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to = router D. Path-1 is then chosen for Flow-1, Path-2 for Flow-2, Path-1 = for Flow 3, etc.=20 >=20 > - In per-datagram scheduling, different datagrams are = transmitted through different paths according to round-robin scheduling. = For example, there are 2 path Tuples (Path-1, Path-2) for the = destination router D. A series of datagrams (Packet-1, Packet-2, = Packet-3, ... etc.) are to be sent to router D. Path-1 is then chosen = for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc.=20 >=20 > Per-flow scheduling is recommended for transport layer protocols that = require strict ordering of the datagrams such as TCP. By default, = per-flow scheduling is used. Per-Datagram scheduling is recommended for = transport layer protocols that have less constraint on datagram arriving = order such as UDP. In lossy networks, per-datagram scheduling is also = recommended. =20 > Other path scheduling mechanisms are also possible and will not impact = the interoperability of different implementations. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > If it looks good for you, we will make the modification in the next = revision of the draft.=20 >=20 > regards >=20 > Jiazi >=20 >=20 >=20 >> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Jiazi, >>=20 >> sorry for my very late reply. Please see below. >>=20 >>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi : >>>=20 >>> Dear Mirja,=20 >>>=20 >>> Thanks very much for your review and comments. Please find the reply = inline:=20 >>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> The following text in section 4 seems to indicate that scheduling = is done >>>> on a per-packet basis: >>>> "When there is a >>>> datagram to be sent to a destination, the source router acquires a >>>> path from the Multi-path Routing Set (MAY be Round-Robin, or other >>>> scheduling algorithms)." >>>> This seems not appropriate as e.g. TCP packets routed on links with >>>> largely different delays may suffer performance. ECMP usually = hashes the >>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and = routes >>>> all packets belonging to the same flow on the same route. I = recommend to >>>> apply the same here. >>>>=20 >>>> Also related is this text in section 8.4 that should explain = Round-Robin >>>> on a per flow basis instead. Further this should only be an example >>>> scheduling alogirthm while text belong seems to assume that = Round-Robin >>>> is always used. >>>> "If a matching Multi-path Routing Tuple is obtained, the Path = Tuples >>>> of the Multi-path Routing Tuple are applied to the datagrams using >>>> Round-robin scheduling. For example, there are 2 path Tuples >>>> (Path-1, Path-2) for destination router D. A series of datagrams >>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. >>>> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 = for >>>> Packet 3, etc. Other path scheduling mechanisms are also possible >>>> and will not impact the interoperability of different >>>> implementations.=E2=80=9D >>>=20 >>> In fact, the per-packet scheduling is an intentional choice because: >>>=20 >>> 1. The aimed scenario is mobile ad hoc networks, which have high = packet loss by nature. One of the most important reasons is route = failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the = packets in disjoint paths (not necessarily equal cost), we can still = make use partial information of the flow, or even reconstruct the flow = with erasure coding. This is especially interesting for video/audio = streaming.=20 >>=20 >> This is only true for unreliable or partially reliable traffic. I see = your use case. However, will if you have TCP traffic, you can probably = assume that the traffic is reliable and should not route on a per-packet = basis. This case is not covered in your draft. Also for other non-TCP = you often might not know much about the traffic characteristics and = therefore cannot know if per-packet scheduling is good or bad. Therefore = default should be per-flow. >>=20 >>>=20 >>> 2. In such kind of lossy networks, the traditional TCP performs very = poor [1]. So as far as I know, TCP is not very popular in ad hoc = networks. On the other hand, based on our study, the multi-path routing = can actually reduce the overall jitter [2].=20 >>=20 >> I didn=E2=80=99t have time to read the whole paper but on a brief = look, it looks like you take the delay into account for TCP traffic. = Which is what I said above: either you have two links which have more or = less the same delay or re-ordering will be wrongly interpreted as = congestion. The other problem is TCP reduces its sending rate due to = loss. So if both links are congested and losses occurred (in a = non-synchronized way), TCP will react to both signals and reduce its = sending rate more than necessary. That's why I would recommend to = schedule TCP as well as other reliable and congestion-controlled traffic = on a per-flow base. Further for UDP traffic there is no good way to = actually know if the traffic is reliably transmitted and congestion = control, so it=E2=80=99s hard to make such a decision in the network in = a general case. >>=20 >>>=20 >>> We understand your concern on this issue (and you can imagine that = you are not the first one who raises this ;). It is also something that = we want to have further experience from this *experimental* draft, as we = stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: >>>=20 >>> =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics.=20 >>> =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath routing, = especially variable latencies. Although current experiment results show = that multipath routing can reduce the jitter in dynamic scenarios, some = transport protocols or applications may be sensitive to the datagram = re-ordering.=20 >>> =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged. >>=20 >> That=E2=80=99s fine but then you cannot assume in the rest of the = document that per-packet scheduling is used. >>=20 >> There are two options to handle this: either you remove the text that = is cited above and do not talk about scheduling at all other than in the = experimentation part, or you explain carefully when potentially = per-packet scheduling could be used and make clear that by default and = especially for TCP per-flow scheduling should be used. >>=20 >>=20 >>>=20 >>>=20 >>> [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf=20 >>> [2] Multipath optimized link state routing for mobile ad hoc = networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, = 2011. >>>=20 >>>>=20 >>>> Related is this text in section 8.4.: >>>> "If datagrams without source routing header need to be forwarded = using >>>> multiple paths (for example, based on the information of DiffServ >>>> Code Point [RFC2474])" >>>> RFC2474 does not specify any application requirements on multipath = use >>>> and as such the DiffServe field should not be used to determine if = the >>>> flow can be routed on multiple paths. The ability to profit from >>>> multipath routing depends not only on the application and protocols = used >>>> but also on the characteristics of the multipath link(s); so it's = hard to >>>> make any implicit assumptions here. However, if routing would only = be >>>> recommended on a per-flow basis this problem does not occur and the >>>> brackets above could be remove. Further, if routed on a per flow = basis >>>> would be done, DiffServ could actually be used to decide which path = to >>>> use, if e.g. one path has a lower delay, but that seem to need = further >>>> discussion as well. >>>=20 >>> As we mentioned before, the multipath routing has special interests = in audio/video streaming applications. For applications that requires = strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.=20 >>=20 >> Which DiffServ codepoints are you taking about? Some of the code = points require low delay but they either say nothing about reordering or = require a bounded jitter as well which mean forwarding on a per-packet = basis over two links which highly different delays should not be done. >>=20 >> Mirja >>=20 >>=20 >>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Minor comments/questions: >>>>=20 >>>> 1) section 8.4: this sentence is not clear: >>>> "It is RECOMMENDED to use MTU sizes considering the source routing >>>> header to avoid fragmentation." >>>> MAYBE >>>> "It is NOT RECOMMENDED to fragment the IP packet if the packet with = the >>>> source routing header would exceed the minimum MTU along the path. = In >>>> this case source routing and therefore the additional path = calculated by >>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D >>>=20 >>> Fixed.=20 >>>=20 >>>>=20 >>>> 2) section 9: >>>> "For IPv6 networks, it MUST >>>> be set to 0, i.e., no constraint on maximum number of hops." >>>> Why is that? >>>=20 >>> Because the current RFC6554 supports only IPv6 strict source = routing, we thus need to keep all the path information in the source = routing header, in which case we don=E2=80=99t know the number of hops.=20= >>>=20 >>> On the other hand, we noticed that the IPv6 segment routing header = is being discussed at 6man, we thus have the following text in the = =E2=80=9CExperiments to be conducted=E2=80=9D section: >>>=20 >>> =E2=80=A2 Use of IPv6 loose source routing. In the current = specification, only strict source routing is used for IPv6 based on = [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routi= ng=E2=80=91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header is = critical, the loose source routing can be considered. >>>=20 >>>>=20 >>>> 3) Not sure why section 12.1. is there? Can this be removed? >>>=20 >>> Removed.=20 >>>=20 >>> Agains, we appreciate your valuable comments and hope that our reply = addresses your concern.=20 >>>=20 >>> regards >>>=20 >>> Jiazi >>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >=20 From nobody Tue May 23 15:26:30 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B5E129B61; Tue, 23 May 2017 15:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXzNOO23RsOv; Tue, 23 May 2017 15:26:17 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C61128AB0; Tue, 23 May 2017 15:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1495578370; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=16789; bh=9yGbcgifCz8JebBPu5+Uh4zLQ8+O/ttBw8DTiU0NAvE=; b=n7+RuzKvRVfzCNamhwHjdmN9nbd4UmkuyOzN28wYVi8wyGWbboLVxZ63bqdA7Tgf xxN2mIF3IKxxvt9OYmOZK26mdEQVpnxpgSOZu2XtvxKF9Bz6P8CPtd7qlItwWMMsN5M rkeWVq9gUaumRuuRcgC22dHv+qBoykbg5jM5zq8c= Received: from [192.168.1.101] (230.248.86.88.rdns.comcable.net [88.86.248.230]) by mx.zohomail.com with SMTPS id 1495578370457666.1792693038692; Tue, 23 May 2017 15:26:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jiazi Yi In-Reply-To: <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> Date: Wed, 24 May 2017 00:26:07 +0200 Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> To: "Mirja Kuehlewind (IETF)" X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 22:26:20 -0000 Hi Mirja,=20 Thanks very much for your input. Now we have the text for section 8.4: > If a matching Multipath Routing Tuple is obtained, the Path Tuples of = the Multipath Routing Tuple are applied to the datagrams using either = per-flow scheduling or per-datagram scheduling, depending on the = transport layer protocol and the application used. By default, per-flow = scheduling is used, especially for the transport protocols that are = sensitive to reordering, such as TCP. The path selection decision is = made on the first datagram and all subsequent datagrams of the same flow = use the same path. If the path is detected broken before the flow is = closed, another path with the most similar metric is used. Per-datagram = scheduling is recommended if the traffic is insensitive to reordering = such as non-reliable transmission of media traffic, or when erasure = coding is applied. In such case, each datagram selects their paths = independently.=20 >=20 > By default, the traffic load is equally distributed in multiple paths. = Other path scheduling mechanisms (e.g., assigning more traffic over = better paths) are also possible and will not impact the interoperability = of different implementations. And we will also rephrase the text in section 4.=20 Let us know if it=E2=80=99s OK for you.=20 best Jiazi > On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) = wrote: >=20 > Hi Jiazi, >=20 > unfortunately, the following sentence is not correct, as basically any = transport can be encapsulated over UDP: >=20 >> Per-Datagram scheduling is recommended for transport layer protocols = that have less constraint on datagram arriving order such as UDP. >=20 > I would propose the following sentence: >=20 >> Per-Datagram scheduling is only recommended if it is known that the = traffic is not sensitive to reordering, e.g. for non-reliable = transmission of media traffic. >=20 > In this case I would further recommend to add the following sentence: >=20 >> Note that the use of paths with highly different delays can still = have a negative impact on these kind of transmissions, as packets that = arrive too late may be ignored and therefore have been transmitted = unnecessarily. >=20 > Further I also don=E2=80=99t agree to this sentence: >=20 >> In lossy networks, per-datagram scheduling is also recommended. >=20 > Even in lossy networks, per-datagram scheduling is still not = recommended for TCP (if the delay of the different paths are too = diverse). >=20 > Finally, I would further recommend you to not say that round-robin = needs to be used in section 8.4. I also don=E2=80=99t think you need to = have the two bullet points that explain what per-datagram and per-flow = means. It=E2=80=99s enough to say that per-flow scheduling means that a = decision is made on the first packet which path to use and all = subsequent packets of the same flow (e.g. identified by the 5- or = 6-tuple) need to use the same path. >=20 > Further please also check section 4 as this also makes assumptions on = the path selection. >=20 > Thanks, > Mirja >=20 >=20 >=20 >> Am 23.05.2017 um 13:49 schrieb Jiazi Yi : >>=20 >> Dear Mirja,=20 >>=20 >> Thank very much for your reply.=20 >>=20 >> We understand your concern on the performance, especially the issue = of packet reordering when the multipath protocol is applied to transport = protocol like TCP. Therefore, we propose to have some guidelines to = indicate when per-flow scheduling is recommended, and when per-packet = scheduling is recommended.=20 >>=20 >> More specifically, in the draft, we propose the text: >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> In section 1.1, Experiments to be conducted: >>=20 >> =E2=80=A2 Different path-selection schedulers. Depending on the = application type and transport layer type either per-flow scheduler or = per-datagram scheduler is applied. By default, round-robin scheduling is = used to select a path to be used. In some scenarios, weighted scheduling = can be considered: for example, the paths with lower metrics (i.e., = higher quality) can transfer more datagrams or flows compared to paths = with higher metrics. >>=20 >>=20 >> In section 8.4, Datagram Processing at the MP-OLSRv2 Originator >>=20 >> If a matching Multipath Routing Tuple is obtained, the Path Tuples of = the Multipath Routing Tuple are applied to the datagrams using = round-robin scheduling. The scheduling policy can be either per-flow or = per-datagram, depending on the transport layer protocol and the = application used:=20 >>=20 >> - In per-flow scheduling, the datagrams of the same flow is = transmitted through the same path. Different flows are assigned to = different paths according to round-robin scheduling. For example, there = are 2 path Tuples (Path-1, Path-2) for the destination router D. A = series of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to = router D. Path-1 is then chosen for Flow-1, Path-2 for Flow-2, Path-1 = for Flow 3, etc.=20 >>=20 >> - In per-datagram scheduling, different datagrams are = transmitted through different paths according to round-robin scheduling. = For example, there are 2 path Tuples (Path-1, Path-2) for the = destination router D. A series of datagrams (Packet-1, Packet-2, = Packet-3, ... etc.) are to be sent to router D. Path-1 is then chosen = for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc.=20 >>=20 >> Per-flow scheduling is recommended for transport layer protocols that = require strict ordering of the datagrams such as TCP. By default, = per-flow scheduling is used. Per-Datagram scheduling is recommended for = transport layer protocols that have less constraint on datagram arriving = order such as UDP. In lossy networks, per-datagram scheduling is also = recommended. =20 >> Other path scheduling mechanisms are also possible and will not = impact the interoperability of different implementations. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> If it looks good for you, we will make the modification in the next = revision of the draft.=20 >>=20 >> regards >>=20 >> Jiazi >>=20 >>=20 >>=20 >>> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi Jiazi, >>>=20 >>> sorry for my very late reply. Please see below. >>>=20 >>>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi : >>>>=20 >>>> Dear Mirja,=20 >>>>=20 >>>> Thanks very much for your review and comments. Please find the = reply inline:=20 >>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> The following text in section 4 seems to indicate that scheduling = is done >>>>> on a per-packet basis: >>>>> "When there is a >>>>> datagram to be sent to a destination, the source router acquires a >>>>> path from the Multi-path Routing Set (MAY be Round-Robin, or other >>>>> scheduling algorithms)." >>>>> This seems not appropriate as e.g. TCP packets routed on links = with >>>>> largely different delays may suffer performance. ECMP usually = hashes the >>>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and = routes >>>>> all packets belonging to the same flow on the same route. I = recommend to >>>>> apply the same here. >>>>>=20 >>>>> Also related is this text in section 8.4 that should explain = Round-Robin >>>>> on a per flow basis instead. Further this should only be an = example >>>>> scheduling alogirthm while text belong seems to assume that = Round-Robin >>>>> is always used. >>>>> "If a matching Multi-path Routing Tuple is obtained, the Path = Tuples >>>>> of the Multi-path Routing Tuple are applied to the datagrams using >>>>> Round-robin scheduling. For example, there are 2 path Tuples >>>>> (Path-1, Path-2) for destination router D. A series of datagrams >>>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. >>>>> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 = for >>>>> Packet 3, etc. Other path scheduling mechanisms are also possible >>>>> and will not impact the interoperability of different >>>>> implementations.=E2=80=9D >>>>=20 >>>> In fact, the per-packet scheduling is an intentional choice = because: >>>>=20 >>>> 1. The aimed scenario is mobile ad hoc networks, which have high = packet loss by nature. One of the most important reasons is route = failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the = packets in disjoint paths (not necessarily equal cost), we can still = make use partial information of the flow, or even reconstruct the flow = with erasure coding. This is especially interesting for video/audio = streaming.=20 >>>=20 >>> This is only true for unreliable or partially reliable traffic. I = see your use case. However, will if you have TCP traffic, you can = probably assume that the traffic is reliable and should not route on a = per-packet basis. This case is not covered in your draft. Also for other = non-TCP you often might not know much about the traffic characteristics = and therefore cannot know if per-packet scheduling is good or bad. = Therefore default should be per-flow. >>>=20 >>>>=20 >>>> 2. In such kind of lossy networks, the traditional TCP performs = very poor [1]. So as far as I know, TCP is not very popular in ad hoc = networks. On the other hand, based on our study, the multi-path routing = can actually reduce the overall jitter [2].=20 >>>=20 >>> I didn=E2=80=99t have time to read the whole paper but on a brief = look, it looks like you take the delay into account for TCP traffic. = Which is what I said above: either you have two links which have more or = less the same delay or re-ordering will be wrongly interpreted as = congestion. The other problem is TCP reduces its sending rate due to = loss. So if both links are congested and losses occurred (in a = non-synchronized way), TCP will react to both signals and reduce its = sending rate more than necessary. That's why I would recommend to = schedule TCP as well as other reliable and congestion-controlled traffic = on a per-flow base. Further for UDP traffic there is no good way to = actually know if the traffic is reliably transmitted and congestion = control, so it=E2=80=99s hard to make such a decision in the network in = a general case. >>>=20 >>>>=20 >>>> We understand your concern on this issue (and you can imagine that = you are not the first one who raises this ;). It is also something that = we want to have further experience from this *experimental* draft, as we = stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: >>>>=20 >>>> =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics.=20 >>>> =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath routing, = especially variable latencies. Although current experiment results show = that multipath routing can reduce the jitter in dynamic scenarios, some = transport protocols or applications may be sensitive to the datagram = re-ordering.=20 >>>> =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged. >>>=20 >>> That=E2=80=99s fine but then you cannot assume in the rest of the = document that per-packet scheduling is used. >>>=20 >>> There are two options to handle this: either you remove the text = that is cited above and do not talk about scheduling at all other than = in the experimentation part, or you explain carefully when potentially = per-packet scheduling could be used and make clear that by default and = especially for TCP per-flow scheduling should be used. >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf=20 >>>> [2] Multipath optimized link state routing for mobile ad hoc = networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, = 2011. >>>>=20 >>>>>=20 >>>>> Related is this text in section 8.4.: >>>>> "If datagrams without source routing header need to be forwarded = using >>>>> multiple paths (for example, based on the information of DiffServ >>>>> Code Point [RFC2474])" >>>>> RFC2474 does not specify any application requirements on multipath = use >>>>> and as such the DiffServe field should not be used to determine if = the >>>>> flow can be routed on multiple paths. The ability to profit from >>>>> multipath routing depends not only on the application and = protocols used >>>>> but also on the characteristics of the multipath link(s); so it's = hard to >>>>> make any implicit assumptions here. However, if routing would only = be >>>>> recommended on a per-flow basis this problem does not occur and = the >>>>> brackets above could be remove. Further, if routed on a per flow = basis >>>>> would be done, DiffServ could actually be used to decide which = path to >>>>> use, if e.g. one path has a lower delay, but that seem to need = further >>>>> discussion as well. >>>>=20 >>>> As we mentioned before, the multipath routing has special interests = in audio/video streaming applications. For applications that requires = strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.=20 >>>=20 >>> Which DiffServ codepoints are you taking about? Some of the code = points require low delay but they either say nothing about reordering or = require a bounded jitter as well which mean forwarding on a per-packet = basis over two links which highly different delays should not be done. >>>=20 >>> Mirja >>>=20 >>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Minor comments/questions: >>>>>=20 >>>>> 1) section 8.4: this sentence is not clear: >>>>> "It is RECOMMENDED to use MTU sizes considering the source routing >>>>> header to avoid fragmentation." >>>>> MAYBE >>>>> "It is NOT RECOMMENDED to fragment the IP packet if the packet = with the >>>>> source routing header would exceed the minimum MTU along the = path. In >>>>> this case source routing and therefore the additional path = calculated by >>>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D >>>>=20 >>>> Fixed.=20 >>>>=20 >>>>>=20 >>>>> 2) section 9: >>>>> "For IPv6 networks, it MUST >>>>> be set to 0, i.e., no constraint on maximum number of hops." >>>>> Why is that? >>>>=20 >>>> Because the current RFC6554 supports only IPv6 strict source = routing, we thus need to keep all the path information in the source = routing header, in which case we don=E2=80=99t know the number of hops.=20= >>>>=20 >>>> On the other hand, we noticed that the IPv6 segment routing header = is being discussed at 6man, we thus have the following text in the = =E2=80=9CExperiments to be conducted=E2=80=9D section: >>>>=20 >>>> =E2=80=A2 Use of IPv6 loose source routing. In the current = specification, only strict source routing is used for IPv6 based on = [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routi= ng=E2=80=91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header is = critical, the loose source routing can be considered. >>>>=20 >>>>>=20 >>>>> 3) Not sure why section 12.1. is there? Can this be removed? >>>>=20 >>>> Removed.=20 >>>>=20 >>>> Agains, we appreciate your valuable comments and hope that our = reply addresses your concern.=20 >>>>=20 >>>> regards >>>>=20 >>>> Jiazi >>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 From nobody Wed May 24 04:29:37 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AF8129572 for ; Wed, 24 May 2017 04:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqb1oVqYd7gp for ; Wed, 24 May 2017 04:29:34 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF6312957A for ; Wed, 24 May 2017 04:29:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=oLY1YJmpd3F1pb95HRqxqVPg8J/1p0CvcCW2ptqXWrbq/Jb2Ey2npx4j1tBLpu1qnCirbtK+4uZ5BJUqGzSNQYip4WRU35Fj/B27s7tjxLoLsbZinp9qlTqBJL3tw/WGztbGrmAtSCuWyp2CWUC7iWh1cKUSWEQjJqUeoygqHIY=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 10020 invoked from network); 24 May 2017 13:22:49 +0200 Received: from pd9e11835.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.24.53) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 24 May 2017 13:22:49 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 24 May 2017 13:22:48 +0200 Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <751656CF-E1E2-4748-BB30-A203D893DE6F@kuehlewind.net> References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> To: Jiazi Yi X-Mailer: Apple Mail (2.3273) X-PPP-Message-ID: <20170524112249.10012.53433@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 11:29:36 -0000 Thanks! That=E2=80=99s much better! Two nits below. Mirja > Am 24.05.2017 um 00:26 schrieb Jiazi Yi : >=20 > Hi Mirja,=20 >=20 > Thanks very much for your input. Now we have the text for section 8.4: >=20 >> If a matching Multipath Routing Tuple is obtained, the Path Tuples of = the Multipath Routing Tuple are applied to the datagrams using either = per-flow scheduling or per-datagram scheduling, depending on the = transport layer protocol and the application used. By default, per-flow = scheduling is used, especially for the transport protocols that are = sensitive to reordering, such as TCP. The path selection decision is = made on the first datagram and all subsequent datagrams of the same flow = use the same path. If the path is detected broken before the flow is = closed, another path with the most similar metric is used. Per-datagram = scheduling is recommended if the traffic is insensitive to reordering = such as non-reliable transmission of media traffic, or when erasure = coding is applied. In such case, each datagram selects their paths = independently.=20 s/each datagram selects their paths/each datagram selects its paths/ >>=20 >> By default, the traffic load is equally distributed in multiple = paths. Other path scheduling Maybe s/the traffic load is equally distributed/the traffic load should be = equally distributed/ >> mechanisms (e.g., assigning more traffic over better paths) are also = possible and will not impact the interoperability of different = implementations. >=20 >=20 > And we will also rephrase the text in section 4.=20 >=20 > Let us know if it=E2=80=99s OK for you.=20 >=20 > best >=20 > Jiazi >=20 >=20 >> On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) = wrote: >>=20 >> Hi Jiazi, >>=20 >> unfortunately, the following sentence is not correct, as basically = any transport can be encapsulated over UDP: >>=20 >>> Per-Datagram scheduling is recommended for transport layer protocols = that have less constraint on datagram arriving order such as UDP. >>=20 >> I would propose the following sentence: >>=20 >>> Per-Datagram scheduling is only recommended if it is known that the = traffic is not sensitive to reordering, e.g. for non-reliable = transmission of media traffic. >>=20 >> In this case I would further recommend to add the following sentence: >>=20 >>> Note that the use of paths with highly different delays can still = have a negative impact on these kind of transmissions, as packets that = arrive too late may be ignored and therefore have been transmitted = unnecessarily. >>=20 >> Further I also don=E2=80=99t agree to this sentence: >>=20 >>> In lossy networks, per-datagram scheduling is also recommended. >>=20 >> Even in lossy networks, per-datagram scheduling is still not = recommended for TCP (if the delay of the different paths are too = diverse). >>=20 >> Finally, I would further recommend you to not say that round-robin = needs to be used in section 8.4. I also don=E2=80=99t think you need to = have the two bullet points that explain what per-datagram and per-flow = means. It=E2=80=99s enough to say that per-flow scheduling means that a = decision is made on the first packet which path to use and all = subsequent packets of the same flow (e.g. identified by the 5- or = 6-tuple) need to use the same path. >>=20 >> Further please also check section 4 as this also makes assumptions on = the path selection. >>=20 >> Thanks, >> Mirja >>=20 >>=20 >>=20 >>> Am 23.05.2017 um 13:49 schrieb Jiazi Yi : >>>=20 >>> Dear Mirja,=20 >>>=20 >>> Thank very much for your reply.=20 >>>=20 >>> We understand your concern on the performance, especially the issue = of packet reordering when the multipath protocol is applied to transport = protocol like TCP. Therefore, we propose to have some guidelines to = indicate when per-flow scheduling is recommended, and when per-packet = scheduling is recommended.=20 >>>=20 >>> More specifically, in the draft, we propose the text: >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> In section 1.1, Experiments to be conducted: >>>=20 >>> =E2=80=A2 Different path-selection schedulers. Depending on the = application type and transport layer type either per-flow scheduler or = per-datagram scheduler is applied. By default, round-robin scheduling is = used to select a path to be used. In some scenarios, weighted scheduling = can be considered: for example, the paths with lower metrics (i.e., = higher quality) can transfer more datagrams or flows compared to paths = with higher metrics. >>>=20 >>>=20 >>> In section 8.4, Datagram Processing at the MP-OLSRv2 Originator >>>=20 >>> If a matching Multipath Routing Tuple is obtained, the Path Tuples = of the Multipath Routing Tuple are applied to the datagrams using = round-robin scheduling. The scheduling policy can be either per-flow or = per-datagram, depending on the transport layer protocol and the = application used:=20 >>>=20 >>> - In per-flow scheduling, the datagrams of the same flow is = transmitted through the same path. Different flows are assigned to = different paths according to round-robin scheduling. For example, there = are 2 path Tuples (Path-1, Path-2) for the destination router D. A = series of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to = router D. Path-1 is then chosen for Flow-1, Path-2 for Flow-2, Path-1 = for Flow 3, etc.=20 >>>=20 >>> - In per-datagram scheduling, different datagrams are = transmitted through different paths according to round-robin scheduling. = For example, there are 2 path Tuples (Path-1, Path-2) for the = destination router D. A series of datagrams (Packet-1, Packet-2, = Packet-3, ... etc.) are to be sent to router D. Path-1 is then chosen = for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc.=20 >>>=20 >>> Per-flow scheduling is recommended for transport layer protocols = that require strict ordering of the datagrams such as TCP. By default, = per-flow scheduling is used. Per-Datagram scheduling is recommended for = transport layer protocols that have less constraint on datagram arriving = order such as UDP. In lossy networks, per-datagram scheduling is also = recommended. =20 >>> Other path scheduling mechanisms are also possible and will not = impact the interoperability of different implementations. >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> If it looks good for you, we will make the modification in the next = revision of the draft.=20 >>>=20 >>> regards >>>=20 >>> Jiazi >>>=20 >>>=20 >>>=20 >>>> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) = wrote: >>>>=20 >>>> Hi Jiazi, >>>>=20 >>>> sorry for my very late reply. Please see below. >>>>=20 >>>>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi : >>>>>=20 >>>>> Dear Mirja,=20 >>>>>=20 >>>>> Thanks very much for your review and comments. Please find the = reply inline:=20 >>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> The following text in section 4 seems to indicate that scheduling = is done >>>>>> on a per-packet basis: >>>>>> "When there is a >>>>>> datagram to be sent to a destination, the source router acquires = a >>>>>> path from the Multi-path Routing Set (MAY be Round-Robin, or = other >>>>>> scheduling algorithms)." >>>>>> This seems not appropriate as e.g. TCP packets routed on links = with >>>>>> largely different delays may suffer performance. ECMP usually = hashes the >>>>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and = routes >>>>>> all packets belonging to the same flow on the same route. I = recommend to >>>>>> apply the same here. >>>>>>=20 >>>>>> Also related is this text in section 8.4 that should explain = Round-Robin >>>>>> on a per flow basis instead. Further this should only be an = example >>>>>> scheduling alogirthm while text belong seems to assume that = Round-Robin >>>>>> is always used. >>>>>> "If a matching Multi-path Routing Tuple is obtained, the Path = Tuples >>>>>> of the Multi-path Routing Tuple are applied to the datagrams = using >>>>>> Round-robin scheduling. For example, there are 2 path Tuples >>>>>> (Path-1, Path-2) for destination router D. A series of datagrams >>>>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. >>>>>> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 = for >>>>>> Packet 3, etc. Other path scheduling mechanisms are also = possible >>>>>> and will not impact the interoperability of different >>>>>> implementations.=E2=80=9D >>>>>=20 >>>>> In fact, the per-packet scheduling is an intentional choice = because: >>>>>=20 >>>>> 1. The aimed scenario is mobile ad hoc networks, which have high = packet loss by nature. One of the most important reasons is route = failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the = packets in disjoint paths (not necessarily equal cost), we can still = make use partial information of the flow, or even reconstruct the flow = with erasure coding. This is especially interesting for video/audio = streaming.=20 >>>>=20 >>>> This is only true for unreliable or partially reliable traffic. I = see your use case. However, will if you have TCP traffic, you can = probably assume that the traffic is reliable and should not route on a = per-packet basis. This case is not covered in your draft. Also for other = non-TCP you often might not know much about the traffic characteristics = and therefore cannot know if per-packet scheduling is good or bad. = Therefore default should be per-flow. >>>>=20 >>>>>=20 >>>>> 2. In such kind of lossy networks, the traditional TCP performs = very poor [1]. So as far as I know, TCP is not very popular in ad hoc = networks. On the other hand, based on our study, the multi-path routing = can actually reduce the overall jitter [2].=20 >>>>=20 >>>> I didn=E2=80=99t have time to read the whole paper but on a brief = look, it looks like you take the delay into account for TCP traffic. = Which is what I said above: either you have two links which have more or = less the same delay or re-ordering will be wrongly interpreted as = congestion. The other problem is TCP reduces its sending rate due to = loss. So if both links are congested and losses occurred (in a = non-synchronized way), TCP will react to both signals and reduce its = sending rate more than necessary. That's why I would recommend to = schedule TCP as well as other reliable and congestion-controlled traffic = on a per-flow base. Further for UDP traffic there is no good way to = actually know if the traffic is reliably transmitted and congestion = control, so it=E2=80=99s hard to make such a decision in the network in = a general case. >>>>=20 >>>>>=20 >>>>> We understand your concern on this issue (and you can imagine that = you are not the first one who raises this ;). It is also something that = we want to have further experience from this *experimental* draft, as we = stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: >>>>>=20 >>>>> =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics.=20 >>>>> =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath routing, = especially variable latencies. Although current experiment results show = that multipath routing can reduce the jitter in dynamic scenarios, some = transport protocols or applications may be sensitive to the datagram = re-ordering.=20 >>>>> =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged. >>>>=20 >>>> That=E2=80=99s fine but then you cannot assume in the rest of the = document that per-packet scheduling is used. >>>>=20 >>>> There are two options to handle this: either you remove the text = that is cited above and do not talk about scheduling at all other than = in the experimentation part, or you explain carefully when potentially = per-packet scheduling could be used and make clear that by default and = especially for TCP per-flow scheduling should be used. >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf=20 >>>>> [2] Multipath optimized link state routing for mobile ad hoc = networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, = 2011. >>>>>=20 >>>>>>=20 >>>>>> Related is this text in section 8.4.: >>>>>> "If datagrams without source routing header need to be forwarded = using >>>>>> multiple paths (for example, based on the information of DiffServ >>>>>> Code Point [RFC2474])" >>>>>> RFC2474 does not specify any application requirements on = multipath use >>>>>> and as such the DiffServe field should not be used to determine = if the >>>>>> flow can be routed on multiple paths. The ability to profit from >>>>>> multipath routing depends not only on the application and = protocols used >>>>>> but also on the characteristics of the multipath link(s); so it's = hard to >>>>>> make any implicit assumptions here. However, if routing would = only be >>>>>> recommended on a per-flow basis this problem does not occur and = the >>>>>> brackets above could be remove. Further, if routed on a per flow = basis >>>>>> would be done, DiffServ could actually be used to decide which = path to >>>>>> use, if e.g. one path has a lower delay, but that seem to need = further >>>>>> discussion as well. >>>>>=20 >>>>> As we mentioned before, the multipath routing has special = interests in audio/video streaming applications. For applications that = requires strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.=20 >>>>=20 >>>> Which DiffServ codepoints are you taking about? Some of the code = points require low delay but they either say nothing about reordering or = require a bounded jitter as well which mean forwarding on a per-packet = basis over two links which highly different delays should not be done. >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> Minor comments/questions: >>>>>>=20 >>>>>> 1) section 8.4: this sentence is not clear: >>>>>> "It is RECOMMENDED to use MTU sizes considering the source = routing >>>>>> header to avoid fragmentation." >>>>>> MAYBE >>>>>> "It is NOT RECOMMENDED to fragment the IP packet if the packet = with the >>>>>> source routing header would exceed the minimum MTU along the = path. In >>>>>> this case source routing and therefore the additional path = calculated by >>>>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D >>>>>=20 >>>>> Fixed.=20 >>>>>=20 >>>>>>=20 >>>>>> 2) section 9: >>>>>> "For IPv6 networks, it MUST >>>>>> be set to 0, i.e., no constraint on maximum number of hops." >>>>>> Why is that? >>>>>=20 >>>>> Because the current RFC6554 supports only IPv6 strict source = routing, we thus need to keep all the path information in the source = routing header, in which case we don=E2=80=99t know the number of hops.=20= >>>>>=20 >>>>> On the other hand, we noticed that the IPv6 segment routing header = is being discussed at 6man, we thus have the following text in the = =E2=80=9CExperiments to be conducted=E2=80=9D section: >>>>>=20 >>>>> =E2=80=A2 Use of IPv6 loose source routing. In the current = specification, only strict source routing is used for IPv6 based on = [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routi= ng=E2=80=91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header is = critical, the loose source routing can be considered. >>>>>=20 >>>>>>=20 >>>>>> 3) Not sure why section 12.1. is there? Can this be removed? >>>>>=20 >>>>> Removed.=20 >>>>>=20 >>>>> Agains, we appreciate your valuable comments and hope that our = reply addresses your concern.=20 >>>>>=20 >>>>> regards >>>>>=20 >>>>> Jiazi >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >=20 >=20 From nobody Wed May 24 05:19:54 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 071C6129AD5; Wed, 24 May 2017 05:19:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149562838500.28549.18303601990308966364@ietfa.amsl.com> Date: Wed, 24 May 2017 05:19:45 -0700 Archived-At: Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-15.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 12:19:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Multipath Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-15.txt Pages : 26 Date : 2017-05-24 Abstract: This document specifies a multipath extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-15 https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 24 05:33:18 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6597129ADF; Wed, 24 May 2017 05:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jiaziyi.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSO_fwjY1DEV; Wed, 24 May 2017 05:33:06 -0700 (PDT) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E62129BBE; Wed, 24 May 2017 05:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1495629179; s=jiazi; d=jiaziyi.com; i=ietf@jiaziyi.com; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=43029; bh=Rd1uCWgi/gHLyrVBU3GxGKgXK/HhpRi2gDz9fZIgPpM=; b=VBRqZmYW5VPl5Cq+2JN6z9AN5SqV9Mjf3HZpfeEyfSkvOmk/8SylHP1TAFgYO3dq 4jiyHhzH94DM1pomsVApedr4InYkahTHFQa2eYLtzXvxLLfkb5Yc7wpx4WRFRs5BcV1 8GW9PjVDOM+s7tmF9ERwkbETelcb4Vdv6ntyauPI= Received: from [129.104.74.24] (129.104.74.24 [129.104.74.24]) by mx.zohomail.com with SMTPS id 1495629179454951.25958646522; Wed, 24 May 2017 05:32:59 -0700 (PDT) From: Jiazi Yi Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0942747E-A1A5-49A6-A225-04D544B26731" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 24 May 2017 14:32:56 +0200 In-Reply-To: <751656CF-E1E2-4748-BB30-A203D893DE6F@kuehlewind.net> Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org, manet-chairs@ietf.org To: "Mirja Kuehlewind (IETF)" References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> <751656CF-E1E2-4748-BB30-A203D893DE6F@kuehlewind.net> X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 12:33:10 -0000 --Apple-Mail=_0942747E-A1A5-49A6-A225-04D544B26731 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Mirja:=20 Thanks very much! We just submitted a new revision based on our = discussion:=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-15 = > = https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-multipath-15= = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-15= = = Hopefully this revision have addressed your concern.=20 best Jiazi > On 24 May 2017, at 13:22, Mirja Kuehlewind (IETF) = wrote: >=20 > Thanks! That=E2=80=99s much better! >=20 > Two nits below. >=20 > Mirja >=20 >=20 >> Am 24.05.2017 um 00:26 schrieb Jiazi Yi : >>=20 >> Hi Mirja,=20 >>=20 >> Thanks very much for your input. Now we have the text for section = 8.4: >>=20 >>> If a matching Multipath Routing Tuple is obtained, the Path Tuples = of the Multipath Routing Tuple are applied to the datagrams using either = per-flow scheduling or per-datagram scheduling, depending on the = transport layer protocol and the application used. By default, per-flow = scheduling is used, especially for the transport protocols that are = sensitive to reordering, such as TCP. The path selection decision is = made on the first datagram and all subsequent datagrams of the same flow = use the same path. If the path is detected broken before the flow is = closed, another path with the most similar metric is used. Per-datagram = scheduling is recommended if the traffic is insensitive to reordering = such as non-reliable transmission of media traffic, or when erasure = coding is applied. In such case, each datagram selects their paths = independently.=20 >=20 > s/each datagram selects their paths/each datagram selects its paths/ >=20 >>>=20 >>> By default, the traffic load is equally distributed in multiple = paths. Other path scheduling >=20 > Maybe > s/the traffic load is equally distributed/the traffic load should be = equally distributed/ >=20 >>> mechanisms (e.g., assigning more traffic over better paths) are also = possible and will not impact the interoperability of different = implementations. >>=20 >>=20 >> And we will also rephrase the text in section 4.=20 >>=20 >> Let us know if it=E2=80=99s OK for you.=20 >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >>> On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) = wrote: >>>=20 >>> Hi Jiazi, >>>=20 >>> unfortunately, the following sentence is not correct, as basically = any transport can be encapsulated over UDP: >>>=20 >>>> Per-Datagram scheduling is recommended for transport layer = protocols that have less constraint on datagram arriving order such as = UDP. >>>=20 >>> I would propose the following sentence: >>>=20 >>>> Per-Datagram scheduling is only recommended if it is known that the = traffic is not sensitive to reordering, e.g. for non-reliable = transmission of media traffic. >>>=20 >>> In this case I would further recommend to add the following = sentence: >>>=20 >>>> Note that the use of paths with highly different delays can still = have a negative impact on these kind of transmissions, as packets that = arrive too late may be ignored and therefore have been transmitted = unnecessarily. >>>=20 >>> Further I also don=E2=80=99t agree to this sentence: >>>=20 >>>> In lossy networks, per-datagram scheduling is also recommended. >>>=20 >>> Even in lossy networks, per-datagram scheduling is still not = recommended for TCP (if the delay of the different paths are too = diverse). >>>=20 >>> Finally, I would further recommend you to not say that round-robin = needs to be used in section 8.4. I also don=E2=80=99t think you need to = have the two bullet points that explain what per-datagram and per-flow = means. It=E2=80=99s enough to say that per-flow scheduling means that a = decision is made on the first packet which path to use and all = subsequent packets of the same flow (e.g. identified by the 5- or = 6-tuple) need to use the same path. >>>=20 >>> Further please also check section 4 as this also makes assumptions = on the path selection. >>>=20 >>> Thanks, >>> Mirja >>>=20 >>>=20 >>>=20 >>>> Am 23.05.2017 um 13:49 schrieb Jiazi Yi : >>>>=20 >>>> Dear Mirja,=20 >>>>=20 >>>> Thank very much for your reply.=20 >>>>=20 >>>> We understand your concern on the performance, especially the issue = of packet reordering when the multipath protocol is applied to transport = protocol like TCP. Therefore, we propose to have some guidelines to = indicate when per-flow scheduling is recommended, and when per-packet = scheduling is recommended.=20 >>>>=20 >>>> More specifically, in the draft, we propose the text: >>>>=20 >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> In section 1.1, Experiments to be conducted: >>>>=20 >>>> =E2=80=A2 Different path-selection schedulers. Depending on the = application type and transport layer type either per-flow scheduler or = per-datagram scheduler is applied. By default, round-robin scheduling is = used to select a path to be used. In some scenarios, weighted scheduling = can be considered: for example, the paths with lower metrics (i.e., = higher quality) can transfer more datagrams or flows compared to paths = with higher metrics. >>>>=20 >>>>=20 >>>> In section 8.4, Datagram Processing at the MP-OLSRv2 Originator >>>>=20 >>>> If a matching Multipath Routing Tuple is obtained, the Path Tuples = of the Multipath Routing Tuple are applied to the datagrams using = round-robin scheduling. The scheduling policy can be either per-flow or = per-datagram, depending on the transport layer protocol and the = application used:=20 >>>>=20 >>>> - In per-flow scheduling, the datagrams of the same flow is = transmitted through the same path. Different flows are assigned to = different paths according to round-robin scheduling. For example, there = are 2 path Tuples (Path-1, Path-2) for the destination router D. A = series of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to = router D. Path-1 is then chosen for Flow-1, Path-2 for Flow-2, Path-1 = for Flow 3, etc.=20 >>>>=20 >>>> - In per-datagram scheduling, different datagrams are = transmitted through different paths according to round-robin scheduling. = For example, there are 2 path Tuples (Path-1, Path-2) for the = destination router D. A series of datagrams (Packet-1, Packet-2, = Packet-3, ... etc.) are to be sent to router D. Path-1 is then chosen = for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc.=20 >>>>=20 >>>> Per-flow scheduling is recommended for transport layer protocols = that require strict ordering of the datagrams such as TCP. By default, = per-flow scheduling is used. Per-Datagram scheduling is recommended for = transport layer protocols that have less constraint on datagram arriving = order such as UDP. In lossy networks, per-datagram scheduling is also = recommended. =20 >>>> Other path scheduling mechanisms are also possible and will not = impact the interoperability of different implementations. >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> If it looks good for you, we will make the modification in the next = revision of the draft.=20 >>>>=20 >>>> regards >>>>=20 >>>> Jiazi >>>>=20 >>>>=20 >>>>=20 >>>>> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) = wrote: >>>>>=20 >>>>> Hi Jiazi, >>>>>=20 >>>>> sorry for my very late reply. Please see below. >>>>>=20 >>>>>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi : >>>>>>=20 >>>>>> Dear Mirja,=20 >>>>>>=20 >>>>>> Thanks very much for your review and comments. Please find the = reply inline:=20 >>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> DISCUSS: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> The following text in section 4 seems to indicate that = scheduling is done >>>>>>> on a per-packet basis: >>>>>>> "When there is a >>>>>>> datagram to be sent to a destination, the source router acquires = a >>>>>>> path from the Multi-path Routing Set (MAY be Round-Robin, or = other >>>>>>> scheduling algorithms)." >>>>>>> This seems not appropriate as e.g. TCP packets routed on links = with >>>>>>> largely different delays may suffer performance. ECMP usually = hashes the >>>>>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and = routes >>>>>>> all packets belonging to the same flow on the same route. I = recommend to >>>>>>> apply the same here. >>>>>>>=20 >>>>>>> Also related is this text in section 8.4 that should explain = Round-Robin >>>>>>> on a per flow basis instead. Further this should only be an = example >>>>>>> scheduling alogirthm while text belong seems to assume that = Round-Robin >>>>>>> is always used. >>>>>>> "If a matching Multi-path Routing Tuple is obtained, the Path = Tuples >>>>>>> of the Multi-path Routing Tuple are applied to the datagrams = using >>>>>>> Round-robin scheduling. For example, there are 2 path Tuples >>>>>>> (Path-1, Path-2) for destination router D. A series of datagrams >>>>>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router = D. >>>>>>> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 = for >>>>>>> Packet 3, etc. Other path scheduling mechanisms are also = possible >>>>>>> and will not impact the interoperability of different >>>>>>> implementations.=E2=80=9D >>>>>>=20 >>>>>> In fact, the per-packet scheduling is an intentional choice = because: >>>>>>=20 >>>>>> 1. The aimed scenario is mobile ad hoc networks, which have high = packet loss by nature. One of the most important reasons is route = failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the = packets in disjoint paths (not necessarily equal cost), we can still = make use partial information of the flow, or even reconstruct the flow = with erasure coding. This is especially interesting for video/audio = streaming.=20 >>>>>=20 >>>>> This is only true for unreliable or partially reliable traffic. I = see your use case. However, will if you have TCP traffic, you can = probably assume that the traffic is reliable and should not route on a = per-packet basis. This case is not covered in your draft. Also for other = non-TCP you often might not know much about the traffic characteristics = and therefore cannot know if per-packet scheduling is good or bad. = Therefore default should be per-flow. >>>>>=20 >>>>>>=20 >>>>>> 2. In such kind of lossy networks, the traditional TCP performs = very poor [1]. So as far as I know, TCP is not very popular in ad hoc = networks. On the other hand, based on our study, the multi-path routing = can actually reduce the overall jitter [2].=20 >>>>>=20 >>>>> I didn=E2=80=99t have time to read the whole paper but on a brief = look, it looks like you take the delay into account for TCP traffic. = Which is what I said above: either you have two links which have more or = less the same delay or re-ordering will be wrongly interpreted as = congestion. The other problem is TCP reduces its sending rate due to = loss. So if both links are congested and losses occurred (in a = non-synchronized way), TCP will react to both signals and reduce its = sending rate more than necessary. That's why I would recommend to = schedule TCP as well as other reliable and congestion-controlled traffic = on a per-flow base. Further for UDP traffic there is no good way to = actually know if the traffic is reliably transmitted and congestion = control, so it=E2=80=99s hard to make such a decision in the network in = a general case. >>>>>=20 >>>>>>=20 >>>>>> We understand your concern on this issue (and you can imagine = that you are not the first one who raises this ;). It is also something = that we want to have further experience from this *experimental* draft, = as we stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D = section: >>>>>>=20 >>>>>> =E2=80=A2 Different path-selection schedulers. By default, = round-robin scheduling is used to select a path to be used for = datagrams. In some scenarios, weighted scheduling can be considered: for = example, the paths with lower metrics (i.e., higher quality) can = transfer more datagrams compared to paths with higher metrics.=20 >>>>>> =E2=80=A2 The impacts of the delay variation due to multipath = routing. [RFC2991] brings out some concerns of multipath routing, = especially variable latencies. Although current experiment results show = that multipath routing can reduce the jitter in dynamic scenarios, some = transport protocols or applications may be sensitive to the datagram = re-ordering.=20 >>>>>> =E2=80=A2 The disjoint multipath protocol has interesting = application with erasure coding, especially for services like = video/audio streaming [WPMC11]. The combination of erasure coding = mechanisms and this extension is thus encouraged. >>>>>=20 >>>>> That=E2=80=99s fine but then you cannot assume in the rest of the = document that per-packet scheduling is used. >>>>>=20 >>>>> There are two options to handle this: either you remove the text = that is cited above and do not talk about scheduling at all other than = in the experimentation part, or you explain carefully when potentially = per-packet scheduling could be used and make clear that by default and = especially for TCP per-flow scheduling should be used. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks = https://arxiv.org/pdf/1002.2189.pdf=20 >>>>>> [2] Multipath optimized link state routing for mobile ad hoc = networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, = 2011. >>>>>>=20 >>>>>>>=20 >>>>>>> Related is this text in section 8.4.: >>>>>>> "If datagrams without source routing header need to be forwarded = using >>>>>>> multiple paths (for example, based on the information of = DiffServ >>>>>>> Code Point [RFC2474])" >>>>>>> RFC2474 does not specify any application requirements on = multipath use >>>>>>> and as such the DiffServe field should not be used to determine = if the >>>>>>> flow can be routed on multiple paths. The ability to profit from >>>>>>> multipath routing depends not only on the application and = protocols used >>>>>>> but also on the characteristics of the multipath link(s); so = it's hard to >>>>>>> make any implicit assumptions here. However, if routing would = only be >>>>>>> recommended on a per-flow basis this problem does not occur and = the >>>>>>> brackets above could be remove. Further, if routed on a per flow = basis >>>>>>> would be done, DiffServ could actually be used to decide which = path to >>>>>>> use, if e.g. one path has a lower delay, but that seem to need = further >>>>>>> discussion as well. >>>>>>=20 >>>>>> As we mentioned before, the multipath routing has special = interests in audio/video streaming applications. For applications that = requires strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.=20 >>>>>=20 >>>>> Which DiffServ codepoints are you taking about? Some of the code = points require low delay but they either say nothing about reordering or = require a bounded jitter as well which mean forwarding on a per-packet = basis over two links which highly different delays should not be done. >>>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> Minor comments/questions: >>>>>>>=20 >>>>>>> 1) section 8.4: this sentence is not clear: >>>>>>> "It is RECOMMENDED to use MTU sizes considering the source = routing >>>>>>> header to avoid fragmentation." >>>>>>> MAYBE >>>>>>> "It is NOT RECOMMENDED to fragment the IP packet if the packet = with the >>>>>>> source routing header would exceed the minimum MTU along the = path. In >>>>>>> this case source routing and therefore the additional path = calculated by >>>>>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D >>>>>>=20 >>>>>> Fixed.=20 >>>>>>=20 >>>>>>>=20 >>>>>>> 2) section 9: >>>>>>> "For IPv6 networks, it MUST >>>>>>> be set to 0, i.e., no constraint on maximum number of hops." >>>>>>> Why is that? >>>>>>=20 >>>>>> Because the current RFC6554 supports only IPv6 strict source = routing, we thus need to keep all the path information in the source = routing header, in which case we don=E2=80=99t know the number of hops.=20= >>>>>>=20 >>>>>> On the other hand, we noticed that the IPv6 segment routing = header is being discussed at 6man, we thus have the following text in = the =E2=80=9CExperiments to be conducted=E2=80=9D section: >>>>>>=20 >>>>>> =E2=80=A2 Use of IPv6 loose source routing. In the current = specification, only strict source routing is used for IPv6 based on = [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routi= ng=E2=80=91header], the use of loose source routing is also proposed in = IPv6. In scenarios where the length of the source routing header is = critical, the loose source routing can be considered. >>>>>>=20 >>>>>>>=20 >>>>>>> 3) Not sure why section 12.1. is there? Can this be removed? >>>>>>=20 >>>>>> Removed.=20 >>>>>>=20 >>>>>> Agains, we appreciate your valuable comments and hope that our = reply addresses your concern.=20 >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> Jiazi >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> manet mailing list >>>>>>> manet@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>=20 >>=20 >=20 --Apple-Mail=_0942747E-A1A5-49A6-A225-04D544B26731 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Mirja: 

Thanks very much! We just submitted a = new revision based on our discussion: 


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multip= ath/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-1= 5
https://datatracker.ietf.org/doc/html/draft-ietf-manet-olsrv2-m= ultipath-15

A diff from the previous = version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mul= tipath-15

Hopefully this revision have addressed your = concern. 

best

Jiazi


On = 24 May 2017, at 13:22, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Thanks! That=E2=80=99s much better!

Two nits below.

Mirja


Am 24.05.2017 um 00:26 schrieb Jiazi Yi <ietf@jiaziyi.com>:

Hi Mirja,

Thanks = very much for your input. Now we have the text for section 8.4:

If a = matching Multipath Routing Tuple is obtained, the Path Tuples of the = Multipath Routing Tuple are applied to the datagrams using either = per-flow scheduling or per-datagram scheduling, depending on the = transport layer protocol and the application used. By default, per-flow = scheduling is used, especially for the transport protocols that are = sensitive to reordering, such as TCP. The path selection decision is = made on the first datagram and all subsequent datagrams of the same flow = use the same path. If the path is detected broken before the flow is = closed, another path with the most similar metric is used. Per-datagram = scheduling is recommended if the traffic is insensitive to reordering = such as non-reliable transmission of media traffic, or when erasure = coding is applied. In such case, each datagram selects their paths = independently.

s/each datagram selects their paths/each datagram selects its = paths/


By = default, the traffic load is equally distributed in multiple paths. = Other path scheduling

Maybe
s/the traffic load is equally = distributed/the traffic load should be equally distributed/

mechanisms (e.g., assigning more traffic over = better paths) are also possible and will not impact the interoperability = of different implementations.


And we will also rephrase the text in section = 4.

Let us know if it=E2=80=99s OK for you. =

best

Jiazi


On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Hi Jiazi,

unfortunately, the following sentence is not correct, as = basically any transport can be encapsulated over UDP:

Per-Datagram scheduling = is recommended for transport layer protocols that have less constraint = on datagram arriving order such as UDP.

I would propose the following sentence:

Per-Datagram scheduling = is only recommended if it is known that the traffic is not sensitive to = reordering, e.g. for non-reliable transmission of media traffic.

In this case I would further = recommend to add the following sentence:

Note that the use of = paths with highly different delays can still have a negative impact on = these kind of transmissions, as packets that arrive too late may be = ignored and therefore have been transmitted unnecessarily.

Further I also don=E2=80=99t = agree to this sentence:

In lossy networks, per-datagram scheduling is = also recommended.

Even in = lossy networks, per-datagram scheduling is still not recommended for TCP = (if the delay of the different paths are too diverse).

Finally, I would further recommend you to not say that = round-robin needs to be used in section 8.4. I also don=E2=80=99t think = you need to have the two bullet points that explain what per-datagram = and per-flow means. It=E2=80=99s enough to say that per-flow scheduling = means that a decision is made on the first packet which path to use and = all subsequent packets of the same flow (e.g. identified by the 5- or = 6-tuple) need to use the same path.

Further = please also check section 4 as this also makes assumptions on the path = selection.

Thanks,
Mirja



Am 23.05.2017 um 13:49 schrieb Jiazi Yi <ietf@jiaziyi.com>:

Dear Mirja,

Thank = very much for your reply.

We understand = your concern on the performance, especially the issue of packet = reordering when the multipath protocol is applied to transport protocol = like TCP. Therefore, we propose to have some guidelines to indicate when = per-flow scheduling is recommended, and when per-packet scheduling is = recommended.

More specifically, in the = draft, we propose the text:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
In section 1.1, = Experiments to be conducted:

=E2=80=A2 = Different path-selection schedulers. Depending on the application type = and transport layer type either per-flow scheduler or per-datagram = scheduler is applied. By default, round-robin scheduling is used to = select a path to be used. In some scenarios, weighted scheduling can be = considered: for example, the paths with lower metrics (i.e., higher = quality) can transfer more datagrams or flows compared to paths with = higher metrics.


In section = 8.4, Datagram Processing at the MP-OLSRv2 Originator

If a matching Multipath Routing Tuple is obtained, the Path = Tuples of the Multipath Routing Tuple are applied to the datagrams using = round-robin scheduling. The scheduling policy can be either per-flow or = per-datagram, depending on the transport layer protocol and the = application used:

- In = per-flow scheduling, the datagrams of the same flow is transmitted = through the same path. Different flows are assigned to different paths = according to round-robin scheduling. For example, there are 2 path = Tuples (Path-1, Path-2) for the destination router D. A series of flows = (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to router D. Path-1 is = then chosen for Flow-1, Path-2 for Flow-2, Path-1 for Flow 3, etc.

- In per-datagram scheduling, = different datagrams are transmitted through different paths according to = round-robin scheduling. For example, there are 2 path Tuples (Path-1, = Path-2) for the destination router D. A series of datagrams (Packet-1, = Packet-2, Packet-3, ... etc.) are to be sent to router D. Path-1 is then = chosen for Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc.

Per-flow scheduling is recommended for = transport layer protocols that require strict ordering of the datagrams = such as TCP. By default, per-flow scheduling is used. Per-Datagram = scheduling is recommended for transport layer protocols that have less = constraint on datagram arriving order such as UDP. In lossy networks, = per-datagram scheduling is also recommended.  
Other = path scheduling mechanisms are also possible and will not impact the = interoperability of different implementations.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If it looks good for you, we will make the modification in = the next revision of the draft.

regards

Jiazi



On 22 May = 2017, at 12:17, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>= wrote:

Hi Jiazi,

sorry for my very late reply. Please see below.

Am = 10.05.2017 um 00:51 schrieb Jiazi Yi <ietf@jiaziyi.com>:

Dear Mirja,

Thanks= very much for your review and comments. Please find the reply inline: =

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

The following text in section 4 = seems to indicate that scheduling is done
on a per-packet = basis:
"When there is a
datagram to be sent = to a destination, the source router acquires a
path from = the Multi-path Routing Set (MAY be Round-Robin, or other
scheduling algorithms)."
This seems not = appropriate as e.g. TCP packets routed on links with
largely= different delays may suffer performance. ECMP usually hashes the
5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state = and routes
all packets belonging to the same flow on the = same route. I recommend to
apply the same here.

Also related is this text in section 8.4 that = should explain Round-Robin
on a per flow basis instead. = Further this should only be an example
scheduling = alogirthm while text belong seems to assume that Round-Robin
is always used.
"If a matching Multi-path = Routing Tuple is obtained, the Path Tuples
of the = Multi-path Routing Tuple are applied to the datagrams using
Round-robin scheduling.  For example, there are 2 path = Tuples
(Path-1, Path-2) for destination router D. A series = of datagrams
(Packet-1, Packet-2, Packet-3, ... etc.) are = to be sent router D.
Path-1 is then chosen for Packet-1, = Path-2 for Packet-2, Path-1 for
Packet 3, etc.  Other = path scheduling mechanisms are also possible
and will not = impact the interoperability of different
implementations.=E2=80=9D

In fact, the per-packet scheduling is an intentional choice = because:

1. The aimed scenario is mobile ad = hoc networks, which have high packet loss by nature. One of the most = important reasons is route failure due to mobility =E2=80=94 in such = case, if a per-flow scheduling is applied, the whole flow will lost. On = the other hand, if we send the packets in disjoint paths (not = necessarily equal cost), we can still make use partial information of = the flow, or even reconstruct the flow with erasure coding. This is = especially interesting for video/audio streaming.

This is only true for unreliable = or partially reliable traffic. I see your use case. However, will if you = have TCP traffic, you can probably assume that the traffic is reliable = and should not route on a per-packet basis. This case is not covered in = your draft. Also for other non-TCP you often might not know much about = the traffic characteristics and therefore cannot know if per-packet = scheduling is good or bad. Therefore default should be per-flow.


2. In such kind of lossy networks, the traditional TCP = performs very poor [1]. So as far as I know, TCP is not very popular in = ad hoc networks. On the other hand, based on our study, the multi-path = routing can actually reduce the overall jitter [2].

I didn=E2=80=99t have time to = read the whole paper but on a brief look, it looks like you take the = delay into account for TCP traffic. Which is what I said above: either = you have two links which have more or less the same delay or re-ordering = will be wrongly interpreted as congestion. The other problem is TCP = reduces its sending rate due to loss. So if both links are congested and = losses occurred (in a non-synchronized way), TCP will react to both = signals and reduce its sending rate more than necessary. That's why I = would recommend to schedule TCP as well as other reliable and = congestion-controlled traffic on a per-flow base. Further for UDP = traffic there is no good way to actually know if the traffic is reliably = transmitted and congestion control, so it=E2=80=99s hard to make such a = decision in the network in a general case.


We = understand your concern on this issue (and you can imagine that you are = not the first one who raises this ;). It is also something that we want = to have further experience from this *experimental* draft, as we stated = in the =E2=80=9Cexperiments to be conducted=E2=80=9D section:

=E2=80=A2 Different = path-selection schedulers. By default, round-robin scheduling is used to = select a path to be used for datagrams. In some scenarios, weighted = scheduling can be considered: for example, the paths with lower metrics = (i.e., higher quality) can transfer more datagrams compared to paths = with higher metrics.
=E2=80=A2 The impacts of the = delay variation due to multipath routing. [RFC2991] brings out some = concerns of multipath routing, especially variable latencies. Although = current experiment results show that multipath routing can reduce the = jitter in dynamic scenarios, some transport protocols or applications = may be sensitive to the datagram re-ordering.
=E2=80=A2 = The disjoint multipath protocol has interesting application with erasure = coding, especially for services like video/audio streaming [WPMC11]. The = combination of erasure coding mechanisms and this extension is thus = encouraged.

That=E2=80=99s = fine but then you cannot assume in the rest of the document that = per-packet scheduling is used.

There are = two options to handle this: either you remove the text that is cited = above and do not talk about scheduling at all other than in the = experimentation part, or you explain carefully when potentially = per-packet scheduling could be used and make clear that by default and = especially for TCP per-flow scheduling should be used.




[1] Performance Evaluation of TCP over Mobile = Ad-hoc Networks https://arxiv.org/pdf/1002.2189.pdf
[2] = Multipath optimized link state routing for mobile ad hoc networks", In = Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, 2011.


Related is this text in section 8.4.:
"If = datagrams without source routing header need to be forwarded using
multiple paths (for example, based on the information of = DiffServ
Code Point [RFC2474])"
RFC2474 does = not specify any application requirements on multipath use
and as such the DiffServe field should not be used to = determine if the
flow can be routed on multiple paths. The = ability to profit from
multipath routing depends not only = on the application and protocols used
but also on the = characteristics of the multipath link(s); so it's hard to
make any implicit assumptions here. However, if routing would = only be
recommended on a per-flow basis this problem does = not occur and the
brackets above could be remove. Further, = if routed on a per flow basis
would be done, DiffServ = could actually be used to decide which path to
use, if = e.g. one path has a lower delay, but that seem to need further
discussion as well.

As we mentioned before, the multipath routing has special = interests in audio/video streaming applications. For applications that = requires strict ordering, single path can be used. For streaming and = time-critical applications, the multi-path application might be more = interesting, which can be identified by the DiffServe information.

Which DiffServ codepoints are you = taking about? Some of the code points require low delay but they either = say nothing about reordering or require a bounded jitter as well which = mean forwarding on a per-packet basis over two links which highly = different delays should not be done.

Mirja




---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Minor comments/questions:

1) section 8.4: this sentence is not clear:
"It is RECOMMENDED to use MTU sizes considering the source = routing
header to avoid fragmentation."
MAYBE
"It is NOT RECOMMENDED to fragment the IP = packet if the packet with the
source routing header would =  exceed the minimum MTU along the path. In
this case = source routing and therefore the additional path calculated by
MP-OLSRv2 SHOULD NOT be used.=E2=80=9D

Fixed.


2) = section 9:
"For IPv6 networks, it MUST
=  be set to 0, i.e., no constraint on maximum number of hops."
Why is that?

Because = the current RFC6554 supports only IPv6 strict source routing, we thus = need to keep all the path information in the source routing header, in = which case we don=E2=80=99t know the number of hops.

On the other hand, we noticed that the IPv6 segment routing = header is being discussed at 6man, we thus have the following text in = the =E2=80=9CExperiments to be conducted=E2=80=9D section:

=E2=80=A2 Use of IPv6 loose = source routing. In the current specification, only strict source routing = is used for IPv6 based on [RFC6554]. In = [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routing=E2=80=91hea= der], the use of loose source routing is also proposed in IPv6. In = scenarios where the length of the source routing header is critical, the = loose source routing can be considered.


3) Not = sure why section 12.1. is there? Can this be removed?

Removed.

Agains, we appreciate your valuable comments and hope that = our reply addresses your concern.

regards
Jiazi



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






= --Apple-Mail=_0942747E-A1A5-49A6-A225-04D544B26731-- From nobody Fri May 26 08:37:16 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD5D1200FC; Fri, 26 May 2017 08:37:09 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZAoujJBLUnl; Fri, 26 May 2017 08:37:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B1012E9A1; Fri, 26 May 2017 08:36:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B5F23B81D91; Fri, 26 May 2017 08:36:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, manet@ietf.org Message-Id: <20170526153635.B5F23B81D91@rfc-editor.org> Date: Fri, 26 May 2017 08:36:35 -0700 (PDT) Archived-At: Subject: [manet] RFC 8116 on Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 15:37:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8116 Title: Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) Author: T. Clausen, U. Herberg, J. Yi Status: Informational Stream: IETF Date: May 2017 Mailbox: T.Clausen@computer.org, ulrich@herberg.name, jiazi@jiaziyi.com Pages: 26 Characters: 59118 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-manet-olsrv2-sec-threats-04.txt URL: https://www.rfc-editor.org/info/rfc8116 DOI: 10.17487/RFC8116 This document analyzes common security threats to the Optimized Link State Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated. This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri May 26 08:52:16 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0121C12E957; Fri, 26 May 2017 08:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jij_HTDFHSjc; Fri, 26 May 2017 08:52:04 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03562129AC7; Fri, 26 May 2017 08:52:04 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id t26so11510540qtg.0; Fri, 26 May 2017 08:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FJCkDom8TJdwbJFc1Ycirr0fQKlro06fmp0RpR2QJ94=; b=OnxgTCVCmbwprUl2/1UlvLZwB9ZJZN/uVZKLwMK6Rfm2z1JsLYd4PoGAm5Pir/GFH+ kAPapziW8ZMDtW1PquGZYmicLgQ1QObXmf/Gbb9z1r+A9ifsXQlyA9L+6gW1+FPyZPiL 06QxQuhF00eVflqIPDbigKeGojAsdLmCv6ceNCLDa1yATUSxvtP41Nxlg9DsJ+nf3nAR +gA6ZCm/mIXJOU17+p0T34IckkngxD4Nw1FaVCIPopmAH/pc3h/+v4d5ywgQIKHI8Kt5 PcKCz8rHR9rRUYmo9hGDrvT72I1eX6Jo4dbB3NVzcXRZ41CRcs0W+qug5zWZy1JAaMDL xc/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJCkDom8TJdwbJFc1Ycirr0fQKlro06fmp0RpR2QJ94=; b=YKtRdJb42isvNWz3NYEr1UcF4FqlmWe/GYN3ZnO0WfRJ3kGomO41QkD1nNgknazihp YCdELYo22XEelayEGSLX/9SV0NTfycN6tw2LlPH6ht27HCVLIBq2cDjqaXgdJ9fzj+P+ YnRVwZjEOZAfkX2irb0Oyjfklb3BdeHTWvGt3g4veMM9ogimbCX57w1u+qCx4Tsbv9sR yLpBuIvwtYbMYXgvxgNOlm/BKM4cEn4bU8VEPkzTbGBa3+tICZ30r0G5RafzMet6puLF appTbziu0R+YE4PJOiqppaTznjMy22HiahcWrgIY4J1gHNsfCk64tup0HGI486JtOhBc jNtw== X-Gm-Message-State: AODbwcBen00bPz6SVc9WdFnbIV9lMNhTKbv+R96W8cx2XcZ5Ew+66IoP NfR193muOdE8pp9eyFDgp7vFOo/yEVMq X-Received: by 10.237.34.142 with SMTP id p14mr3156391qtc.90.1495813923028; Fri, 26 May 2017 08:52:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.52 with HTTP; Fri, 26 May 2017 08:52:02 -0700 (PDT) In-Reply-To: <751656CF-E1E2-4748-BB30-A203D893DE6F@kuehlewind.net> References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> <751656CF-E1E2-4748-BB30-A203D893DE6F@kuehlewind.net> From: Abdussalam Baryun Date: Fri, 26 May 2017 17:52:02 +0200 Message-ID: To: "Mirja Kuehlewind (IETF)" Cc: manet , The IESG , draft-ietf-manet-olsrv2-multipath@ietf.org Content-Type: multipart/alternative; boundary="001a1137751e8842ae05506f514a" Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 15:52:15 -0000 --001a1137751e8842ae05506f514a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, and IESG, You first mentioned TCP or reliability in your first message and authors replying too, but IMO, in MANET WG drafts under IETF we still have no routing through TCP because our MANET-Packet as in RFC5444, is only having as mentioned in RFC5498 the IP number 138 and the UDP port number. So our OLSRv2 routers don't do any TCP ports. Regarding reliability, I don't think it is right to mention the reliability in MANET/this-draft, because it may need many other considerations. I think that we need to clarify in this draft the manet packet rfc5444, and that it takes the manet messages including the multipaths. So in the draft mentions datagram, but not manet packet which is 5444 packet, is our source routing at ip layer or transport layer do we need ip number or transport port number. We need to add the below to section 12 as it was done in rfc7181 and 7722: Expert Review: Evaluation Guidelines: For the registry where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444], [RFC5498], [RFC7631] and [RFC7722]. This draft is using the same header type of rfc6554 which I may disagree. Furthermore, in RFC6554 routing has mentioned in its IANA section the assigned ipv6 number is 3 for RPL source routing (this draft is not for RPL), so for this multipath-protocol, we need to assign an IPv4 number for the manet-source-routing, and we should mention it in section 12 as using 138 for IPv6 for manet packets 5444. As we have done in MANET DSR source routing RFC4728 assigned it for IPv4 number 48. In section 12 we need to update the table -1 to have a title similar to 7722 which is: Type 7 Message TLV Type Extensions however, and that we add the references and type extensions of 0 and 1 which were allocated already. Add references in table 1 as 7181 and 7722. take care, AB On Wed, May 24, 2017 at 1:22 PM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Thanks! That=E2=80=99s much better! > > Two nits below. > > Mirja > > > > Am 24.05.2017 um 00:26 schrieb Jiazi Yi : > > > > Hi Mirja, > > > > Thanks very much for your input. Now we have the text for section 8.4: > > > >> If a matching Multipath Routing Tuple is obtained, the Path Tuples of > the Multipath Routing Tuple are applied to the datagrams using either > per-flow scheduling or per-datagram scheduling, depending on the transpor= t > layer protocol and the application used. By default, per-flow scheduling = is > used, especially for the transport protocols that are sensitive to > reordering, such as TCP. The path selection decision is made on the first > datagram and all subsequent datagrams of the same flow use the same path. > If the path is detected broken before the flow is closed, another path wi= th > the most similar metric is used. Per-datagram scheduling is recommended i= f > the traffic is insensitive to reordering such as non-reliable transmissio= n > of media traffic, or when erasure coding is applied. In such case, each > datagram selects their paths independently. > > s/each datagram selects their paths/each datagram selects its paths/ > > >> > >> By default, the traffic load is equally distributed in multiple paths. > Other path scheduling > > Maybe > s/the traffic load is equally distributed/the traffic load should be > equally distributed/ > > >> mechanisms (e.g., assigning more traffic over better paths) are also > possible and will not impact the interoperability of different > implementations. > > > > > > And we will also rephrase the text in section 4. > > > > Let us know if it=E2=80=99s OK for you. > > > > best > > > > Jiazi > > > > > >> On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) > wrote: > >> > >> Hi Jiazi, > >> > >> unfortunately, the following sentence is not correct, as basically any > transport can be encapsulated over UDP: > >> > >>> Per-Datagram scheduling is recommended for transport layer protocols > that have less constraint on datagram arriving order such as UDP. > >> > >> I would propose the following sentence: > >> > >>> Per-Datagram scheduling is only recommended if it is known that the > traffic is not sensitive to reordering, e.g. for non-reliable transmissio= n > of media traffic. > >> > >> In this case I would further recommend to add the following sentence: > >> > >>> Note that the use of paths with highly different delays can still hav= e > a negative impact on these kind of transmissions, as packets that arrive > too late may be ignored and therefore have been transmitted unnecessarily= . > >> > >> Further I also don=E2=80=99t agree to this sentence: > >> > >>> In lossy networks, per-datagram scheduling is also recommended. > >> > >> Even in lossy networks, per-datagram scheduling is still not > recommended for TCP (if the delay of the different paths are too diverse)= . > >> > >> Finally, I would further recommend you to not say that round-robin > needs to be used in section 8.4. I also don=E2=80=99t think you need to h= ave the > two bullet points that explain what per-datagram and per-flow means. It= =E2=80=99s > enough to say that per-flow scheduling means that a decision is made on t= he > first packet which path to use and all subsequent packets of the same flo= w > (e.g. identified by the 5- or 6-tuple) need to use the same path. > >> > >> Further please also check section 4 as this also makes assumptions on > the path selection. > >> > >> Thanks, > >> Mirja > >> > >> > >> > >>> Am 23.05.2017 um 13:49 schrieb Jiazi Yi : > >>> > >>> Dear Mirja, > >>> > >>> Thank very much for your reply. > >>> > >>> We understand your concern on the performance, especially the issue o= f > packet reordering when the multipath protocol is applied to transport > protocol like TCP. Therefore, we propose to have some guidelines to > indicate when per-flow scheduling is recommended, and when per-packet > scheduling is recommended. > >>> > >>> More specifically, in the draft, we propose the text: > >>> > >>> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> In section 1.1, Experiments to be conducted: > >>> > >>> =E2=80=A2 Different path-selection schedulers. Depending on the > application type and transport layer type either per-flow scheduler or > per-datagram scheduler is applied. By default, round-robin scheduling is > used to select a path to be used. In some scenarios, weighted scheduling > can be considered: for example, the paths with lower metrics (i.e., highe= r > quality) can transfer more datagrams or flows compared to paths with high= er > metrics. > >>> > >>> > >>> In section 8.4, Datagram Processing at the MP-OLSRv2 Originator > >>> > >>> If a matching Multipath Routing Tuple is obtained, the Path Tuples of > the Multipath Routing Tuple are applied to the datagrams using round-robi= n > scheduling. The scheduling policy can be either per-flow or per-datagram, > depending on the transport layer protocol and the application used: > >>> > >>> - In per-flow scheduling, the datagrams of the same flow is > transmitted through the same path. Different flows are assigned to > different paths according to round-robin scheduling. For example, there a= re > 2 path Tuples (Path-1, Path-2) for the destination router D. A series of > flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to router D. Path= -1 > is then chosen for Flow-1, Path-2 for Flow-2, Path-1 for Flow 3, etc. > >>> > >>> - In per-datagram scheduling, different datagrams are transmitted > through different paths according to round-robin scheduling. For example, > there are 2 path Tuples (Path-1, Path-2) for the destination router D. A > series of datagrams (Packet-1, Packet-2, Packet-3, ... etc.) are to be se= nt > to router D. Path-1 is then chosen for Packet-1, Path-2 for Packet-2, > Path-1 for Packet 3, etc. > >>> > >>> Per-flow scheduling is recommended for transport layer protocols that > require strict ordering of the datagrams such as TCP. By default, per-flo= w > scheduling is used. Per-Datagram scheduling is recommended for transport > layer protocols that have less constraint on datagram arriving order such > as UDP. In lossy networks, per-datagram scheduling is also recommended. > >>> Other path scheduling mechanisms are also possible and will not impac= t > the interoperability of different implementations. > >>> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> If it looks good for you, we will make the modification in the next > revision of the draft. > >>> > >>> regards > >>> > >>> Jiazi > >>> > >>> > >>> > >>>> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > >>>> > >>>> Hi Jiazi, > >>>> > >>>> sorry for my very late reply. Please see below. > >>>> > >>>>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi : > >>>>> > >>>>> Dear Mirja, > >>>>> > >>>>> Thanks very much for your review and comments. Please find the repl= y > inline: > >>>>> > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> DISCUSS: > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> > >>>>>> The following text in section 4 seems to indicate that scheduling > is done > >>>>>> on a per-packet basis: > >>>>>> "When there is a > >>>>>> datagram to be sent to a destination, the source router acquires a > >>>>>> path from the Multi-path Routing Set (MAY be Round-Robin, or other > >>>>>> scheduling algorithms)." > >>>>>> This seems not appropriate as e.g. TCP packets routed on links wit= h > >>>>>> largely different delays may suffer performance. ECMP usually > hashes the > >>>>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and > routes > >>>>>> all packets belonging to the same flow on the same route. I > recommend to > >>>>>> apply the same here. > >>>>>> > >>>>>> Also related is this text in section 8.4 that should explain > Round-Robin > >>>>>> on a per flow basis instead. Further this should only be an exampl= e > >>>>>> scheduling alogirthm while text belong seems to assume that > Round-Robin > >>>>>> is always used. > >>>>>> "If a matching Multi-path Routing Tuple is obtained, the Path Tupl= es > >>>>>> of the Multi-path Routing Tuple are applied to the datagrams using > >>>>>> Round-robin scheduling. For example, there are 2 path Tuples > >>>>>> (Path-1, Path-2) for destination router D. A series of datagrams > >>>>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. > >>>>>> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 fo= r > >>>>>> Packet 3, etc. Other path scheduling mechanisms are also possible > >>>>>> and will not impact the interoperability of different > >>>>>> implementations.=E2=80=9D > >>>>> > >>>>> In fact, the per-packet scheduling is an intentional choice because= : > >>>>> > >>>>> 1. The aimed scenario is mobile ad hoc networks, which have high > packet loss by nature. One of the most important reasons is route failure > due to mobility =E2=80=94 in such case, if a per-flow scheduling is appli= ed, the > whole flow will lost. On the other hand, if we send the packets in disjoi= nt > paths (not necessarily equal cost), we can still make use partial > information of the flow, or even reconstruct the flow with erasure coding= . > This is especially interesting for video/audio streaming. > >>>> > >>>> This is only true for unreliable or partially reliable traffic. I se= e > your use case. However, will if you have TCP traffic, you can probably > assume that the traffic is reliable and should not route on a per-packet > basis. This case is not covered in your draft. Also for other non-TCP you > often might not know much about the traffic characteristics and therefore > cannot know if per-packet scheduling is good or bad. Therefore default > should be per-flow. > >>>> > >>>>> > >>>>> 2. In such kind of lossy networks, the traditional TCP performs ver= y > poor [1]. So as far as I know, TCP is not very popular in ad hoc networks= . > On the other hand, based on our study, the multi-path routing can actuall= y > reduce the overall jitter [2]. > >>>> > >>>> I didn=E2=80=99t have time to read the whole paper but on a brief lo= ok, it > looks like you take the delay into account for TCP traffic. Which is what= I > said above: either you have two links which have more or less the same > delay or re-ordering will be wrongly interpreted as congestion. The other > problem is TCP reduces its sending rate due to loss. So if both links are > congested and losses occurred (in a non-synchronized way), TCP will react > to both signals and reduce its sending rate more than necessary. That's w= hy > I would recommend to schedule TCP as well as other reliable and > congestion-controlled traffic on a per-flow base. Further for UDP traffic > there is no good way to actually know if the traffic is reliably > transmitted and congestion control, so it=E2=80=99s hard to make such a d= ecision in > the network in a general case. > >>>> > >>>>> > >>>>> We understand your concern on this issue (and you can imagine that > you are not the first one who raises this ;). It is also something that w= e > want to have further experience from this *experimental* draft, as we > stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: > >>>>> > >>>>> =E2=80=A2 Different path-selection schedulers. By default, round-= robin > scheduling is used to select a path to be used for datagrams. In some > scenarios, weighted scheduling can be considered: for example, the paths > with lower metrics (i.e., higher quality) can transfer more datagrams > compared to paths with higher metrics. > >>>>> =E2=80=A2 The impacts of the delay variation due to multipath rou= ting. > [RFC2991] brings out some concerns of multipath routing, especially > variable latencies. Although current experiment results show that multipa= th > routing can reduce the jitter in dynamic scenarios, some transport > protocols or applications may be sensitive to the datagram re-ordering. > >>>>> =E2=80=A2 The disjoint multipath protocol has interesting applica= tion with > erasure coding, especially for services like video/audio streaming > [WPMC11]. The combination of erasure coding mechanisms and this extension > is thus encouraged. > >>>> > >>>> That=E2=80=99s fine but then you cannot assume in the rest of the do= cument > that per-packet scheduling is used. > >>>> > >>>> There are two options to handle this: either you remove the text tha= t > is cited above and do not talk about scheduling at all other than in the > experimentation part, or you explain carefully when potentially per-packe= t > scheduling could be used and make clear that by default and especially fo= r > TCP per-flow scheduling should be used. > >>>> > >>>> > >>>>> > >>>>> > >>>>> [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks > https://arxiv.org/pdf/1002.2189.pdf > >>>>> [2] Multipath optimized link state routing for mobile ad hoc > networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, 2011. > >>>>> > >>>>>> > >>>>>> Related is this text in section 8.4.: > >>>>>> "If datagrams without source routing header need to be forwarded > using > >>>>>> multiple paths (for example, based on the information of DiffServ > >>>>>> Code Point [RFC2474])" > >>>>>> RFC2474 does not specify any application requirements on multipath > use > >>>>>> and as such the DiffServe field should not be used to determine if > the > >>>>>> flow can be routed on multiple paths. The ability to profit from > >>>>>> multipath routing depends not only on the application and protocol= s > used > >>>>>> but also on the characteristics of the multipath link(s); so it's > hard to > >>>>>> make any implicit assumptions here. However, if routing would only > be > >>>>>> recommended on a per-flow basis this problem does not occur and th= e > >>>>>> brackets above could be remove. Further, if routed on a per flow > basis > >>>>>> would be done, DiffServ could actually be used to decide which pat= h > to > >>>>>> use, if e.g. one path has a lower delay, but that seem to need > further > >>>>>> discussion as well. > >>>>> > >>>>> As we mentioned before, the multipath routing has special interests > in audio/video streaming applications. For applications that requires > strict ordering, single path can be used. For streaming and time-critical > applications, the multi-path application might be more interesting, which > can be identified by the DiffServe information. > >>>> > >>>> Which DiffServ codepoints are you taking about? Some of the code > points require low delay but they either say nothing about reordering or > require a bounded jitter as well which mean forwarding on a per-packet > basis over two links which highly different delays should not be done. > >>>> > >>>> Mirja > >>>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> COMMENT: > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> > >>>>>> Minor comments/questions: > >>>>>> > >>>>>> 1) section 8.4: this sentence is not clear: > >>>>>> "It is RECOMMENDED to use MTU sizes considering the source routing > >>>>>> header to avoid fragmentation." > >>>>>> MAYBE > >>>>>> "It is NOT RECOMMENDED to fragment the IP packet if the packet wit= h > the > >>>>>> source routing header would exceed the minimum MTU along the path= . > In > >>>>>> this case source routing and therefore the additional path > calculated by > >>>>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D > >>>>> > >>>>> Fixed. > >>>>> > >>>>>> > >>>>>> 2) section 9: > >>>>>> "For IPv6 networks, it MUST > >>>>>> be set to 0, i.e., no constraint on maximum number of hops." > >>>>>> Why is that? > >>>>> > >>>>> Because the current RFC6554 supports only IPv6 strict source > routing, we thus need to keep all the path information in the source > routing header, in which case we don=E2=80=99t know the number of hops. > >>>>> > >>>>> On the other hand, we noticed that the IPv6 segment routing header > is being discussed at 6man, we thus have the following text in the > =E2=80=9CExperiments to be conducted=E2=80=9D section: > >>>>> > >>>>> =E2=80=A2 Use of IPv6 loose source routing. In the current specif= ication, > only strict source routing is used for IPv6 based on [RFC6554]. In > [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routing=E2=80=91he= ader], the use of loose source routing > is also proposed in IPv6. In scenarios where the length of the source > routing header is critical, the loose source routing can be considered. > >>>>> > >>>>>> > >>>>>> 3) Not sure why section 12.1. is there? Can this be removed? > >>>>> > >>>>> Removed. > >>>>> > >>>>> Agains, we appreciate your valuable comments and hope that our repl= y > addresses your concern. > >>>>> > >>>>> regards > >>>>> > >>>>> Jiazi > >>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> manet mailing list > >>>>>> manet@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/manet > >>> > >> > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1137751e8842ae05506f514a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja, and IESG,

You firs= t mentioned TCP or reliability=C2=A0in your first message and authors reply= ing too, but IMO, in MANET WG drafts under IETF=C2=A0we still have no routi= ng through TCP because our MANET-Packet as in RFC5444, is only having as me= ntioned in RFC5498 the IP number 138 and the UDP port number. So our OLSRv2= routers don't do=C2=A0any TCP ports. Regarding reliability, I don'= t think it is right to mention the reliability in MANET/this-draft, because= it may need many other considerations.

I think th= at we need to clarify in this =C2=A0draft the manet packet rfc5444, and tha= t it takes the manet messages including the multipaths. So in the draft men= tions datagram, but not manet packet which is 5444 packet, is our source ro= uting at ip layer or transport layer do we need ip number or transport port= number.

We need to add the below to section 12 as= it was done in rfc7181 and 7722:

Expert Review: E= valuation Guidelines:
=C2=A0=C2=A0 For the registry where an Expert Revi= ew is required, the designated
=C2=A0=C2=A0 expert SHOULD take the same = general recommendations into
=C2=A0=C2=A0 consideration as are specified= by [RFC5444], [RFC5498], [RFC7631] and=C2=A0[RFC7722].

This draft is using the same header type of rfc6554 which I may disag= ree. Furthermore, in RFC6554 routing has mentioned in its IANA section the = assigned ipv6 number is 3 for RPL source routing (this draft is not for RPL= ), so for this multipath-protocol, we need to assign an IPv4 number for the= manet-source-routing,=C2=A0and =C2=A0we should mention it in section 12 as= using 138 for IPv6 for manet packets 5444. As we have done in MANET DSR so= urce routing RFC4728 assigned it for IPv4 number 48.=C2=A0

In section 12 we need to update the table -1 to have a title simil= ar to 7722 which is:

Type 7 Message TLV Type Exten= sions

however, and that we add the references and = type extensions of 0 and 1 which were allocated already.=C2=A0Add reference= s in table 1 as 7181 and 7722.

take care,
AB


On Wed, May 24, 2017 at 1:22 PM, Mirja= Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
Thanks! That=E2=80=99s much better!

Two nits below.

Mirja


> Am 24.05.2017 um 00:26 schrieb Jiazi Yi <ietf@jiaziyi.com>:
>
> Hi Mirja,
>
> Thanks very much for your input. Now we have the text for section 8.4:=
>
>> If a matching Multipath Routing Tuple is obtained, the Path Tuples= of the Multipath Routing Tuple are applied to the datagrams using either p= er-flow scheduling or per-datagram scheduling, depending on the transport l= ayer protocol and the application used. By default, per-flow scheduling is = used, especially for the transport protocols that are sensitive to reorderi= ng, such as TCP. The path selection decision is made on the first datagram = and all subsequent datagrams of the same flow use the same path. If the pat= h is detected broken before the flow is closed, another path with the most = similar metric is used. Per-datagram scheduling is recommended if the traff= ic is insensitive to reordering such as non-reliable transmission of media = traffic, or when erasure coding is applied. In such case, each datagram sel= ects their paths independently.

s/each datagram selects their paths/each datagram selects its paths/=

>>
>> By default, the traffic load is equally distributed in multiple pa= ths. Other path scheduling

Maybe
s/the traffic load is equally distributed/the traffic load should be equall= y distributed/

>>=C2=A0 mechanisms (e.g., assigning more traffic over better paths) = are also possible and will not impact the interoperability of different imp= lementations.
>
>
> And we will also rephrase the text in section 4.
>
> Let us know if it=E2=80=99s OK for you.
>
> best
>
> Jiazi
>
>
>> On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
>>
>> Hi Jiazi,
>>
>> unfortunately, the following sentence is not correct, as basically= any transport can be encapsulated over UDP:
>>
>>> Per-Datagram scheduling is recommended for transport layer pro= tocols that have less constraint on datagram arriving order such as UDP. >>
>> I would propose the following sentence:
>>
>>> Per-Datagram scheduling is only recommended if it is known tha= t the traffic is not sensitive to reordering, e.g. for non-reliable transmi= ssion of media traffic.
>>
>> In this case I would further recommend to add the following senten= ce:
>>
>>> Note that the use of paths with highly different delays can st= ill have a negative impact on these kind of transmissions, as packets that = arrive too late may be ignored and therefore have been transmitted unnecess= arily.
>>
>> Further I also don=E2=80=99t agree to this sentence:
>>
>>> In lossy networks, per-datagram scheduling is also recommended= .
>>
>> Even in lossy networks, per-datagram scheduling is still not recom= mended for TCP (if the delay of the different paths are too diverse).
>>
>> Finally, I would further recommend you to not say that round-robin= needs to be used in section 8.4. I also don=E2=80=99t think you need to ha= ve the two bullet points that explain what per-datagram and per-flow means.= It=E2=80=99s enough to say that per-flow scheduling means that a decision = is made on the first packet which path to use and all subsequent packets of= the same flow (e.g. identified by the 5- or 6-tuple) need to use the same = path.
>>
>> Further please also check section 4 as this also makes assumptions= on the path selection.
>>
>> Thanks,
>> Mirja
>>
>>
>>
>>> Am 23.05.2017 um 13:49 schrieb Jiazi Yi <ietf@jiaziyi.com>:
>>>
>>> Dear Mirja,
>>>
>>> Thank very much for your reply.
>>>
>>> We understand your concern on the performance, especially the = issue of packet reordering when the multipath protocol is applied to transp= ort protocol like TCP. Therefore, we propose to have some guidelines to ind= icate when per-flow scheduling is recommended, and when per-packet scheduli= ng is recommended.
>>>
>>> More specifically, in the draft, we propose the text:
>>>
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> In section 1.1, Experiments to be conducted:
>>>
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 Different path-selection schedule= rs. Depending on the application type and transport layer type either per-f= low scheduler or per-datagram scheduler is applied. By default, round-robin= scheduling is used to select a path to be used. In some scenarios, weighte= d scheduling can be considered: for example, the paths with lower metrics (= i.e., higher quality) can transfer more datagrams or flows compared to path= s with higher metrics.
>>>
>>>
>>> In section 8.4, Datagram Processing at the MP-OLSRv2 Originato= r
>>>
>>> If a matching Multipath Routing Tuple is obtained, the Path Tu= ples of the Multipath Routing Tuple are applied to the datagrams using roun= d-robin scheduling. The scheduling policy can be either per-flow or per-dat= agram, depending on the transport layer protocol and the application used:<= br> >>>
>>>=C2=A0 =C2=A0 =C2=A0- In per-flow scheduling, the datagrams of = the same flow is transmitted through the same path. Different flows are ass= igned to different paths according to round-robin scheduling. For example, = there are 2 path Tuples (Path-1, Path-2) for the destination router D. A se= ries of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to router D= . Path-1 is then chosen for Flow-1, Path-2 for Flow-2, Path-1 for Flow 3, e= tc.
>>>
>>>=C2=A0 =C2=A0 =C2=A0- In per-datagram scheduling, different dat= agrams are transmitted through different paths according to round-robin sch= eduling. For example, there are 2 path Tuples (Path-1, Path-2) for the dest= ination router D. A series of datagrams (Packet-1, Packet-2, Packet-3, ... = etc.) are to be sent to router D. Path-1 is then chosen for Packet-1, Path-= 2 for Packet-2, Path-1 for Packet 3, etc.
>>>
>>> Per-flow scheduling is recommended for transport layer protoco= ls that require strict ordering of the datagrams such as TCP. By default, p= er-flow scheduling is used. Per-Datagram scheduling is recommended for tran= sport layer protocols that have less constraint on datagram arriving order = such as UDP. In lossy networks, per-datagram scheduling is also recommended= .
>>> Other path scheduling mechanisms are also possible and will no= t impact the interoperability of different implementations.
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> If it looks good for you, we will make the modification in the= next revision of the draft.
>>>
>>> regards
>>>
>>> Jiazi
>>>
>>>
>>>
>>>> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
>>>>
>>>> Hi Jiazi,
>>>>
>>>> sorry for my very late reply. Please see below.
>>>>
>>>>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi <ietf@jiaziyi.com>:
>>>>>
>>>>> Dear Mirja,
>>>>>
>>>>> Thanks very much for your review and comments. Please = find the reply inline:
>>>>>
>>>>>> ---------------------------------------------= -------------------------
>>>>>> DISCUSS:
>>>>>> ---------------------------------------------= -------------------------
>>>>>>
>>>>>> The following text in section 4 seems to indicate = that scheduling is done
>>>>>> on a per-packet basis:
>>>>>> "When there is a
>>>>>> datagram to be sent to a destination, the source r= outer acquires a
>>>>>> path from the Multi-path Routing Set (MAY be Round= -Robin, or other
>>>>>> scheduling algorithms)."
>>>>>> This seems not appropriate as e.g. TCP packets rou= ted on links with
>>>>>> largely different delays may suffer performance. E= CMP usually hashes the
>>>>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to s= etup state and routes
>>>>>> all packets belonging to the same flow on the same= route. I recommend to
>>>>>> apply the same here.
>>>>>>
>>>>>> Also related is this text in section 8.4 that shou= ld explain Round-Robin
>>>>>> on a per flow basis instead. Further this should o= nly be an example
>>>>>> scheduling alogirthm while text belong seems to as= sume that Round-Robin
>>>>>> is always used.
>>>>>> "If a matching Multi-path Routing Tuple is ob= tained, the Path Tuples
>>>>>> of the Multi-path Routing Tuple are applied to the= datagrams using
>>>>>> Round-robin scheduling.=C2=A0 For example, there a= re 2 path Tuples
>>>>>> (Path-1, Path-2) for destination router D. A serie= s of datagrams
>>>>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be= sent router D.
>>>>>> Path-1 is then chosen for Packet-1, Path-2 for Pac= ket-2, Path-1 for
>>>>>> Packet 3, etc.=C2=A0 Other path scheduling mechani= sms are also possible
>>>>>> and will not impact the interoperability of differ= ent
>>>>>> implementations.=E2=80=9D
>>>>>
>>>>> In fact, the per-packet scheduling is an intentional c= hoice because:
>>>>>
>>>>> 1. The aimed scenario is mobile ad hoc networks, which= have high packet loss by nature. One of the most important reasons is rout= e failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the pac= kets in disjoint paths (not necessarily equal cost), we can still make use = partial information of the flow, or even reconstruct the flow with erasure = coding. This is especially interesting for video/audio streaming.
>>>>
>>>> This is only true for unreliable or partially reliable tra= ffic. I see your use case. However, will if you have TCP traffic, you can p= robably assume that the traffic is reliable and should not route on a per-p= acket basis. This case is not covered in your draft. Also for other non-TCP= you often might not know much about the traffic characteristics and theref= ore cannot know if per-packet scheduling is good or bad. Therefore default = should be per-flow.
>>>>
>>>>>
>>>>> 2. In such kind of lossy networks, the traditional TCP= performs very poor [1]. So as far as I know, TCP is not very popular in ad= hoc networks. On the other hand, based on our study, the multi-path routin= g can actually reduce the overall jitter [2].
>>>>
>>>> I didn=E2=80=99t have time to read the whole paper but on = a brief look, it looks like you take the delay into account for TCP traffic= . Which is what I said above: either you have two links which have more or = less the same delay or re-ordering will be wrongly interpreted as congestio= n. The other problem is TCP reduces its sending rate due to loss. So if bot= h links are congested and losses occurred (in a non-synchronized way), TCP = will react to both signals and reduce its sending rate more than necessary.= That's why I would recommend to schedule TCP as well as other reliable= and congestion-controlled traffic on a per-flow base. Further for UDP traf= fic there is no good way to actually know if the traffic is reliably transm= itted and congestion control, so it=E2=80=99s hard to make such a decision = in the network in a general case.
>>>>
>>>>>
>>>>> We understand your concern on this issue (and you can = imagine that you are not the first one who raises this ;). It is also somet= hing that we want to have further experience from this *experimental* draft= , as we stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section= :
>>>>>
>>>>>=C2=A0 =C2=A0=E2=80=A2 Different path-selection schedul= ers. By default, round-robin scheduling is used to select a path to be used= for datagrams. In some scenarios, weighted scheduling can be considered: f= or example, the paths with lower metrics (i.e., higher quality) can transfe= r more datagrams compared to paths with higher metrics.
>>>>>=C2=A0 =C2=A0=E2=80=A2 The impacts of the delay variati= on due to multipath routing. [RFC2991] brings out some concerns of multipat= h routing, especially variable latencies. Although current experiment resul= ts show that multipath routing can reduce the jitter in dynamic scenarios, = some transport protocols or applications may be sensitive to the datagram r= e-ordering.
>>>>>=C2=A0 =C2=A0=E2=80=A2 The disjoint multipath protocol = has interesting application with erasure coding, especially for services li= ke video/audio streaming [WPMC11]. The combination of erasure coding mechan= isms and this extension is thus encouraged.
>>>>
>>>> That=E2=80=99s fine but then you cannot assume in the rest= of the document that per-packet scheduling is used.
>>>>
>>>> There are two options to handle this: either you remove th= e text that is cited above and do not talk about scheduling at all other th= an in the experimentation part, or you explain carefully when potentially p= er-packet scheduling could be used and make clear that by default and espec= ially for TCP per-flow scheduling should be used.
>>>>
>>>>
>>>>>
>>>>>
>>>>> [1] Performance Evaluation of TCP over Mobile Ad-hoc N= etworks https://arxiv.org/pdf/1002.2189.pdf
>>>>> [2] Multipath optimized link state routing for mobile = ad hoc networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, Janu= ary, 2011.
>>>>>
>>>>>>
>>>>>> Related is this text in section 8.4.:
>>>>>> "If datagrams without source routing header n= eed to be forwarded using
>>>>>> multiple paths (for example, based on the informat= ion of DiffServ
>>>>>> Code Point [RFC2474])"
>>>>>> RFC2474 does not specify any application requireme= nts on multipath use
>>>>>> and as such the DiffServe field should not be used= to determine if the
>>>>>> flow can be routed on multiple paths. The ability = to profit from
>>>>>> multipath routing depends not only on the applicat= ion and protocols used
>>>>>> but also on the characteristics of the multipath l= ink(s); so it's hard to
>>>>>> make any implicit assumptions here. However, if ro= uting would only be
>>>>>> recommended on a per-flow basis this problem does = not occur and the
>>>>>> brackets above could be remove. Further, if routed= on a per flow basis
>>>>>> would be done, DiffServ could actually be used to = decide which path to
>>>>>> use, if e.g. one path has a lower delay, but that = seem to need further
>>>>>> discussion as well.
>>>>>
>>>>> As we mentioned before, the multipath routing has spec= ial interests in audio/video streaming applications. For applications that = requires strict ordering, single path can be used. For streaming and time-c= ritical applications, the multi-path application might be more interesting,= which can be identified by the DiffServe information.
>>>>
>>>> Which DiffServ codepoints are you taking about? Some of th= e code points require low delay but they either say nothing about reorderin= g or require a bounded jitter as well which mean forwarding on a per-packet= basis over two links which highly different delays should not be done.
>>>>
>>>> Mirja
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------= -------------------------
>>>>>> COMMENT:
>>>>>> ---------------------------------------------= -------------------------
>>>>>>
>>>>>> Minor comments/questions:
>>>>>>
>>>>>> 1) section 8.4: this sentence is not clear:
>>>>>> "It is RECOMMENDED to use MTU sizes consideri= ng the source routing
>>>>>> header to avoid fragmentation."
>>>>>> MAYBE
>>>>>> "It is NOT RECOMMENDED to fragment the IP pac= ket if the packet with the
>>>>>> source routing header would=C2=A0 exceed the minim= um MTU along the path. In
>>>>>> this case source routing and therefore the additio= nal path calculated by
>>>>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D
>>>>>
>>>>> Fixed.
>>>>>
>>>>>>
>>>>>> 2) section 9:
>>>>>> "For IPv6 networks, it MUST
>>>>>>=C2=A0 =C2=A0be set to 0, i.e., no constraint on ma= ximum number of hops."
>>>>>> Why is that?
>>>>>
>>>>> Because the current RFC6554 supports only IPv6 strict = source routing, we thus need to keep all the path information in the source= routing header, in which case we don=E2=80=99t know the number of hops. >>>>>
>>>>> On the other hand, we noticed that the IPv6 segment ro= uting header is being discussed at 6man, we thus have the following text in= the =E2=80=9CExperiments to be conducted=E2=80=9D section:
>>>>>
>>>>>=C2=A0 =C2=A0=E2=80=A2 Use of IPv6 loose source routing= . In the current specification, only strict source routing is used for IPv6= based on [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2= =80=91routing=E2=80=91header], the use of loose source routing is also= proposed in IPv6. In scenarios where the length of the source routing head= er is critical, the loose source routing can be considered.
>>>>>
>>>>>>
>>>>>> 3) Not sure why section 12.1. is there? Can this b= e removed?
>>>>>
>>>>> Removed.
>>>>>
>>>>> Agains, we appreciate your valuable comments and hope = that our reply addresses your concern.
>>>>>
>>>>> regards
>>>>>
>>>>> Jiazi
>>>>>
>>>>>>
>>>>>>
>>>>>> _____________________________________________= __
>>>>>> manet mailing list
>>>>>> manet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>
>

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

--001a1137751e8842ae05506f514a-- From nobody Fri May 26 09:11:25 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123B012711E; Fri, 26 May 2017 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idirect.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTqhiKk4uSI4; Fri, 26 May 2017 09:11:10 -0700 (PDT) Received: from mx0b-00229401.pphosted.com (mx0b-00229401.pphosted.com [148.163.159.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37814129A8F; Fri, 26 May 2017 09:11:10 -0700 (PDT) Received: from pps.filterd (m0097890.ppops.net [127.0.0.1]) by mx0b-00229401.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4QGB72O030938; Fri, 26 May 2017 12:11:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idirect.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=dk1; bh=cWYkWoNWeUtzP2Czxr1g7suJt6xjOqBriNd4WsHby8U=; b=zriC0PQBOX3+NaMr9334ZkZa0z7Xc70+gcUHf5BYLHbH3YVP77kR0gLHv+FQxFRHnGaX sK0fN3L70ebYJuXJE2By+ojsZSKXh+K34xT5nWpDW2FWGFjVSPY4Pztu4Gwg4+Ac7wat fUcONe+ZIXJ2hI4tyOywj8GnmLfOL9OZvyscOowAxt/5LJioYTwYGJfOfunAAREi/Fjo ukQedqKlVQM3MkNPJ9UP/NlPF0Y9ePiqccEw01PhVEnsRrHvdnabiNdzg5pk50L/NThP G87+uaPDVM/FhKPm6MqcxVBkU9F+9ysUfswXKJCL9e8hHzBbTdyvDxUZKzLawQYIrM4F QA== Received: from webmail.idirect.net ([198.180.159.2]) by mx0b-00229401.pphosted.com with ESMTP id 2ajj4b4fbh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 May 2017 12:11:02 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 26 May 2017 12:11:00 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1263.000; Fri, 26 May 2017 12:11:00 -0400 From: "Ratliff, Stanley" To: Abdussalam Baryun , "Mirja Kuehlewind (IETF)" CC: manet , The IESG , "draft-ietf-manet-olsrv2-multipath@ietf.org" Thread-Topic: =?utf-8?B?W21hbmV0XSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEyOiAod2l0aCBESVNDVVNT?= =?utf-8?Q?_and_COMMENT)?= Thread-Index: AQHS1jgOOEPFprF19EabYMtWbozs+aIGxjlg Date: Fri, 26 May 2017 16:11:00 +0000 Message-ID: References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> <751656CF-E1E2-4748-BB30-A203D893DE6F@kuehlewind.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_b72836e7c79044189181bd5a2fa7995aVAUSDITCHM2idirectnet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-26_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outboundspam_notspam policy=outboundspam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705260291 Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 16:11:16 -0000 --_000_b72836e7c79044189181bd5a2fa7995aVAUSDITCHM2idirectnet_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" QUIsDQoNClRoZSB0ZXh0IHlvdSByZWZlcmVuY2UgaW4gU2VjdGlvbiA4LjQgaXMgdGFsa2luZyBh Ym91dCB0aGUgZGF0YSBiZWluZyByb3V0ZWQ7IG5vdCBhYm91dCB0aGUgY29udHJvbCBwbGFuZSAo T0xTUikgdHJhZmZpYy4gRm9yIGV4YW1wbGUsIGlmIHJlZ3VsYXIgYnJvd3NlciB0cmFmZmljIHdl cmUgdG8gYmUgY2FycmllZCBieSBhbiBPTFNSIG5ldHdvcmsgd2l0aCB0aGUgbXVsdGlwYXRoIGVu aGFuY2VtZW50LCBzYWlkIGJyb3dzZXIgdHJhZmZpYyAod2hpY2ggaXMgVENQLWJhc2VkKSBNVVNU IGJlIGRlbGl2ZXJlZCBieSB0aGUgbmV0d29yayBpbi1zZXF1ZW5jZS4gVGhlIHJlc3RyaWN0aW9u IHN0YXRlZCBpbiBTZWN0aW9uIDguNCBwcmVzZXJ2ZXMgdGhlIG9yZGVyaW5nLCBzaW5jZSB0aGUg dHJhZmZpYyBmb2xsb3dzIHRoZSBzYW1lIHBhdGguDQoNCkFzIHRvIFJGQzU0NDQg4oCTIElJUkMs IHRoZSBXRyBkZWNpc2lvbiBhdCB0aGUgdGltZSB3YXMgdG8gYWxsb3cgZm9yIGJvdGggb3BlcmF0 aW9uIHVzaW5nIFVEUCBhcyBhIHRyYW5zcG9ydCBiZXR3ZWVuIHJvdXRlcnMsIGFzIHdlbGwgYXMg Zm9yIExheWVyIDMgY29tbXVuaWNhdGlvbiAoYXMgT1NQRiBkb2VzKS4gVGhlIGRlY2lzaW9uIG9m IHdoZXRoZXIgdG8gc3VwcG9ydCBVRFAgY29tbXVuaWNhdGlvbiBvciBMYXllciAzIGNvbW11bmlj YXRpb24gaXMgaW1wbGVtZW50YXRpb24tZGVwZW5kZW50LiBBRkFJSywgdGhlcmUgYXJlIG5vIExh eWVyIDMgaW1wbGVtZW50YXRpb25zIHByZXNlbnRseSwgYnV0IGlmIGFueW9uZSBvbiB0aGUgbGlz dCBrbm93cyBvZiBvbmUsIHBsZWFzZSBjb3JyZWN0IG1lLiBIb3dldmVyLCB0aGF0IGlzIHRoZSBy ZWFzb24gYm90aCBhIFVEUCBwb3J0IG51bWJlciBhbmQgYW4gSVAgbnVtYmVyIHdlcmUgYWxsb2Nh dGVkLg0KDQpSZWdhcmRzLA0KU3Rhbg0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBYmR1c3NhbGFtIEJhcnl1bg0KU2VudDogRnJpZGF5 LCBNYXkgMjYsIDIwMTcgMTE6NTIgQU0NClRvOiBNaXJqYSBLdWVobGV3aW5kIChJRVRGKSA8aWV0 ZkBrdWVobGV3aW5kLm5ldD4NCkNjOiBtYW5ldCA8bWFuZXRAaWV0Zi5vcmc+OyBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpcGF0aEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFttYW5ldF0gTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEyOiAod2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKQ0KDQpIaSBNaXJqYSwgYW5kIElFU0csDQoNCllvdSBmaXJzdCBtZW50aW9uZWQgVENQIG9y IHJlbGlhYmlsaXR5IGluIHlvdXIgZmlyc3QgbWVzc2FnZSBhbmQgYXV0aG9ycyByZXBseWluZyB0 b28sIGJ1dCBJTU8sIGluIE1BTkVUIFdHIGRyYWZ0cyB1bmRlciBJRVRGIHdlIHN0aWxsIGhhdmUg bm8gcm91dGluZyB0aHJvdWdoIFRDUCBiZWNhdXNlIG91ciBNQU5FVC1QYWNrZXQgYXMgaW4gUkZD NTQ0NCwgaXMgb25seSBoYXZpbmcgYXMgbWVudGlvbmVkIGluIFJGQzU0OTggdGhlIElQIG51bWJl ciAxMzggYW5kIHRoZSBVRFAgcG9ydCBudW1iZXIuIFNvIG91ciBPTFNSdjIgcm91dGVycyBkb24n dCBkbyBhbnkgVENQIHBvcnRzLiBSZWdhcmRpbmcgcmVsaWFiaWxpdHksIEkgZG9uJ3QgdGhpbmsg aXQgaXMgcmlnaHQgdG8gbWVudGlvbiB0aGUgcmVsaWFiaWxpdHkgaW4gTUFORVQvdGhpcy1kcmFm dCwgYmVjYXVzZSBpdCBtYXkgbmVlZCBtYW55IG90aGVyIGNvbnNpZGVyYXRpb25zLg0KDQpJIHRo aW5rIHRoYXQgd2UgbmVlZCB0byBjbGFyaWZ5IGluIHRoaXMgIGRyYWZ0IHRoZSBtYW5ldCBwYWNr ZXQgcmZjNTQ0NCwgYW5kIHRoYXQgaXQgdGFrZXMgdGhlIG1hbmV0IG1lc3NhZ2VzIGluY2x1ZGlu ZyB0aGUgbXVsdGlwYXRocy4gU28gaW4gdGhlIGRyYWZ0IG1lbnRpb25zIGRhdGFncmFtLCBidXQg bm90IG1hbmV0IHBhY2tldCB3aGljaCBpcyA1NDQ0IHBhY2tldCwgaXMgb3VyIHNvdXJjZSByb3V0 aW5nIGF0IGlwIGxheWVyIG9yIHRyYW5zcG9ydCBsYXllciBkbyB3ZSBuZWVkIGlwIG51bWJlciBv ciB0cmFuc3BvcnQgcG9ydCBudW1iZXIuDQoNCldlIG5lZWQgdG8gYWRkIHRoZSBiZWxvdyB0byBz ZWN0aW9uIDEyIGFzIGl0IHdhcyBkb25lIGluIHJmYzcxODEgYW5kIDc3MjI6DQoNCkV4cGVydCBS ZXZpZXc6IEV2YWx1YXRpb24gR3VpZGVsaW5lczoNCiAgIEZvciB0aGUgcmVnaXN0cnkgd2hlcmUg YW4gRXhwZXJ0IFJldmlldyBpcyByZXF1aXJlZCwgdGhlIGRlc2lnbmF0ZWQNCiAgIGV4cGVydCBT SE9VTEQgdGFrZSB0aGUgc2FtZSBnZW5lcmFsIHJlY29tbWVuZGF0aW9ucyBpbnRvDQogICBjb25z aWRlcmF0aW9uIGFzIGFyZSBzcGVjaWZpZWQgYnkgW1JGQzU0NDRdLCBbUkZDNTQ5OF0sIFtSRkM3 NjMxXSBhbmQgW1JGQzc3MjJdLg0KDQpUaGlzIGRyYWZ0IGlzIHVzaW5nIHRoZSBzYW1lIGhlYWRl ciB0eXBlIG9mIHJmYzY1NTQgd2hpY2ggSSBtYXkgZGlzYWdyZWUuIEZ1cnRoZXJtb3JlLCBpbiBS RkM2NTU0IHJvdXRpbmcgaGFzIG1lbnRpb25lZCBpbiBpdHMgSUFOQSBzZWN0aW9uIHRoZSBhc3Np Z25lZCBpcHY2IG51bWJlciBpcyAzIGZvciBSUEwgc291cmNlIHJvdXRpbmcgKHRoaXMgZHJhZnQg aXMgbm90IGZvciBSUEwpLCBzbyBmb3IgdGhpcyBtdWx0aXBhdGgtcHJvdG9jb2wsIHdlIG5lZWQg dG8gYXNzaWduIGFuIElQdjQgbnVtYmVyIGZvciB0aGUgbWFuZXQtc291cmNlLXJvdXRpbmcsIGFu ZCAgd2Ugc2hvdWxkIG1lbnRpb24gaXQgaW4gc2VjdGlvbiAxMiBhcyB1c2luZyAxMzggZm9yIElQ djYgZm9yIG1hbmV0IHBhY2tldHMgNTQ0NC4gQXMgd2UgaGF2ZSBkb25lIGluIE1BTkVUIERTUiBz b3VyY2Ugcm91dGluZyBSRkM0NzI4IGFzc2lnbmVkIGl0IGZvciBJUHY0IG51bWJlciA0OC4NCg0K SW4gc2VjdGlvbiAxMiB3ZSBuZWVkIHRvIHVwZGF0ZSB0aGUgdGFibGUgLTEgdG8gaGF2ZSBhIHRp dGxlIHNpbWlsYXIgdG8gNzcyMiB3aGljaCBpczoNCg0KVHlwZSA3IE1lc3NhZ2UgVExWIFR5cGUg RXh0ZW5zaW9ucw0KDQpob3dldmVyLCBhbmQgdGhhdCB3ZSBhZGQgdGhlIHJlZmVyZW5jZXMgYW5k IHR5cGUgZXh0ZW5zaW9ucyBvZiAwIGFuZCAxIHdoaWNoIHdlcmUgYWxsb2NhdGVkIGFscmVhZHku IEFkZCByZWZlcmVuY2VzIGluIHRhYmxlIDEgYXMgNzE4MSBhbmQgNzcyMi4NCg0KdGFrZSBjYXJl LA0KQUINCg0KT24gV2VkLCBNYXkgMjQsIDIwMTcgYXQgMToyMiBQTSwgTWlyamEgS3VlaGxld2lu ZCAoSUVURikgPGlldGZAa3VlaGxld2luZC5uZXQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+ PiB3cm90ZToNClRoYW5rcyEgVGhhdOKAmXMgbXVjaCBiZXR0ZXIhDQoNClR3byBuaXRzIGJlbG93 Lg0KDQpNaXJqYQ0KDQoNCj4gQW0gMjQuMDUuMjAxNyB1bSAwMDoyNiBzY2hyaWViIEppYXppIFlp IDxpZXRmQGppYXppeWkuY29tPG1haWx0bzppZXRmQGppYXppeWkuY29tPj46DQo+DQo+IEhpIE1p cmphLA0KPg0KPiBUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIGlucHV0LiBOb3cgd2UgaGF2ZSB0 aGUgdGV4dCBmb3Igc2VjdGlvbiA4LjQ6DQo+DQo+PiBJZiBhIG1hdGNoaW5nIE11bHRpcGF0aCBS b3V0aW5nIFR1cGxlIGlzIG9idGFpbmVkLCB0aGUgUGF0aCBUdXBsZXMgb2YgdGhlIE11bHRpcGF0 aCBSb3V0aW5nIFR1cGxlIGFyZSBhcHBsaWVkIHRvIHRoZSBkYXRhZ3JhbXMgdXNpbmcgZWl0aGVy IHBlci1mbG93IHNjaGVkdWxpbmcgb3IgcGVyLWRhdGFncmFtIHNjaGVkdWxpbmcsIGRlcGVuZGlu ZyBvbiB0aGUgdHJhbnNwb3J0IGxheWVyIHByb3RvY29sIGFuZCB0aGUgYXBwbGljYXRpb24gdXNl ZC4gQnkgZGVmYXVsdCwgcGVyLWZsb3cgc2NoZWR1bGluZyBpcyB1c2VkLCBlc3BlY2lhbGx5IGZv ciB0aGUgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IGFyZSBzZW5zaXRpdmUgdG8gcmVvcmRlcmlu Zywgc3VjaCBhcyBUQ1AuIFRoZSBwYXRoIHNlbGVjdGlvbiBkZWNpc2lvbiBpcyBtYWRlIG9uIHRo ZSBmaXJzdCBkYXRhZ3JhbSBhbmQgYWxsIHN1YnNlcXVlbnQgZGF0YWdyYW1zIG9mIHRoZSBzYW1l IGZsb3cgdXNlIHRoZSBzYW1lIHBhdGguIElmIHRoZSBwYXRoIGlzIGRldGVjdGVkIGJyb2tlbiBi ZWZvcmUgdGhlIGZsb3cgaXMgY2xvc2VkLCBhbm90aGVyIHBhdGggd2l0aCB0aGUgbW9zdCBzaW1p bGFyIG1ldHJpYyBpcyB1c2VkLiBQZXItZGF0YWdyYW0gc2NoZWR1bGluZyBpcyByZWNvbW1lbmRl ZCBpZiB0aGUgdHJhZmZpYyBpcyBpbnNlbnNpdGl2ZSB0byByZW9yZGVyaW5nIHN1Y2ggYXMgbm9u LXJlbGlhYmxlIHRyYW5zbWlzc2lvbiBvZiBtZWRpYSB0cmFmZmljLCBvciB3aGVuIGVyYXN1cmUg Y29kaW5nIGlzIGFwcGxpZWQuIEluIHN1Y2ggY2FzZSwgZWFjaCBkYXRhZ3JhbSBzZWxlY3RzIHRo ZWlyIHBhdGhzIGluZGVwZW5kZW50bHkuDQoNCnMvZWFjaCBkYXRhZ3JhbSBzZWxlY3RzIHRoZWly IHBhdGhzL2VhY2ggZGF0YWdyYW0gc2VsZWN0cyBpdHMgcGF0aHMvDQoNCj4+DQo+PiBCeSBkZWZh dWx0LCB0aGUgdHJhZmZpYyBsb2FkIGlzIGVxdWFsbHkgZGlzdHJpYnV0ZWQgaW4gbXVsdGlwbGUg cGF0aHMuIE90aGVyIHBhdGggc2NoZWR1bGluZw0KDQpNYXliZQ0Kcy90aGUgdHJhZmZpYyBsb2Fk IGlzIGVxdWFsbHkgZGlzdHJpYnV0ZWQvdGhlIHRyYWZmaWMgbG9hZCBzaG91bGQgYmUgZXF1YWxs eSBkaXN0cmlidXRlZC8NCg0KPj4gIG1lY2hhbmlzbXMgKGUuZy4sIGFzc2lnbmluZyBtb3JlIHRy YWZmaWMgb3ZlciBiZXR0ZXIgcGF0aHMpIGFyZSBhbHNvIHBvc3NpYmxlIGFuZCB3aWxsIG5vdCBp bXBhY3QgdGhlIGludGVyb3BlcmFiaWxpdHkgb2YgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucy4N Cj4NCj4NCj4gQW5kIHdlIHdpbGwgYWxzbyByZXBocmFzZSB0aGUgdGV4dCBpbiBzZWN0aW9uIDQu DQo+DQo+IExldCB1cyBrbm93IGlmIGl04oCZcyBPSyBmb3IgeW91Lg0KPg0KPiBiZXN0DQo+DQo+ IEppYXppDQo+DQo+DQo+PiBPbiAyMyBNYXkgMjAxNywgYXQgMTQ6MTAsIE1pcmphIEt1ZWhsZXdp bmQgKElFVEYpIDxpZXRmQGt1ZWhsZXdpbmQubmV0PG1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0 Pj4gd3JvdGU6DQo+Pg0KPj4gSGkgSmlhemksDQo+Pg0KPj4gdW5mb3J0dW5hdGVseSwgdGhlIGZv bGxvd2luZyBzZW50ZW5jZSBpcyBub3QgY29ycmVjdCwgYXMgYmFzaWNhbGx5IGFueSB0cmFuc3Bv cnQgY2FuIGJlIGVuY2Fwc3VsYXRlZCBvdmVyIFVEUDoNCj4+DQo+Pj4gUGVyLURhdGFncmFtIHNj aGVkdWxpbmcgaXMgcmVjb21tZW5kZWQgZm9yIHRyYW5zcG9ydCBsYXllciBwcm90b2NvbHMgdGhh dCBoYXZlIGxlc3MgY29uc3RyYWludCBvbiBkYXRhZ3JhbSBhcnJpdmluZyBvcmRlciBzdWNoIGFz IFVEUC4NCj4+DQo+PiBJIHdvdWxkIHByb3Bvc2UgdGhlIGZvbGxvd2luZyBzZW50ZW5jZToNCj4+ DQo+Pj4gUGVyLURhdGFncmFtIHNjaGVkdWxpbmcgaXMgb25seSByZWNvbW1lbmRlZCBpZiBpdCBp cyBrbm93biB0aGF0IHRoZSB0cmFmZmljIGlzIG5vdCBzZW5zaXRpdmUgdG8gcmVvcmRlcmluZywg ZS5nLiBmb3Igbm9uLXJlbGlhYmxlIHRyYW5zbWlzc2lvbiBvZiBtZWRpYSB0cmFmZmljLg0KPj4N Cj4+IEluIHRoaXMgY2FzZSBJIHdvdWxkIGZ1cnRoZXIgcmVjb21tZW5kIHRvIGFkZCB0aGUgZm9s bG93aW5nIHNlbnRlbmNlOg0KPj4NCj4+PiBOb3RlIHRoYXQgdGhlIHVzZSBvZiBwYXRocyB3aXRo IGhpZ2hseSBkaWZmZXJlbnQgZGVsYXlzIGNhbiBzdGlsbCBoYXZlIGEgbmVnYXRpdmUgaW1wYWN0 IG9uIHRoZXNlIGtpbmQgb2YgdHJhbnNtaXNzaW9ucywgYXMgcGFja2V0cyB0aGF0IGFycml2ZSB0 b28gbGF0ZSBtYXkgYmUgaWdub3JlZCBhbmQgdGhlcmVmb3JlIGhhdmUgYmVlbiB0cmFuc21pdHRl ZCB1bm5lY2Vzc2FyaWx5Lg0KPj4NCj4+IEZ1cnRoZXIgSSBhbHNvIGRvbuKAmXQgYWdyZWUgdG8g dGhpcyBzZW50ZW5jZToNCj4+DQo+Pj4gSW4gbG9zc3kgbmV0d29ya3MsIHBlci1kYXRhZ3JhbSBz Y2hlZHVsaW5nIGlzIGFsc28gcmVjb21tZW5kZWQuDQo+Pg0KPj4gRXZlbiBpbiBsb3NzeSBuZXR3 b3JrcywgcGVyLWRhdGFncmFtIHNjaGVkdWxpbmcgaXMgc3RpbGwgbm90IHJlY29tbWVuZGVkIGZv ciBUQ1AgKGlmIHRoZSBkZWxheSBvZiB0aGUgZGlmZmVyZW50IHBhdGhzIGFyZSB0b28gZGl2ZXJz ZSkuDQo+Pg0KPj4gRmluYWxseSwgSSB3b3VsZCBmdXJ0aGVyIHJlY29tbWVuZCB5b3UgdG8gbm90 IHNheSB0aGF0IHJvdW5kLXJvYmluIG5lZWRzIHRvIGJlIHVzZWQgaW4gc2VjdGlvbiA4LjQuIEkg YWxzbyBkb27igJl0IHRoaW5rIHlvdSBuZWVkIHRvIGhhdmUgdGhlIHR3byBidWxsZXQgcG9pbnRz IHRoYXQgZXhwbGFpbiB3aGF0IHBlci1kYXRhZ3JhbSBhbmQgcGVyLWZsb3cgbWVhbnMuIEl04oCZ cyBlbm91Z2ggdG8gc2F5IHRoYXQgcGVyLWZsb3cgc2NoZWR1bGluZyBtZWFucyB0aGF0IGEgZGVj aXNpb24gaXMgbWFkZSBvbiB0aGUgZmlyc3QgcGFja2V0IHdoaWNoIHBhdGggdG8gdXNlIGFuZCBh bGwgc3Vic2VxdWVudCBwYWNrZXRzIG9mIHRoZSBzYW1lIGZsb3cgKGUuZy4gaWRlbnRpZmllZCBi eSB0aGUgNS0gb3IgNi10dXBsZSkgbmVlZCB0byB1c2UgdGhlIHNhbWUgcGF0aC4NCj4+DQo+PiBG dXJ0aGVyIHBsZWFzZSBhbHNvIGNoZWNrIHNlY3Rpb24gNCBhcyB0aGlzIGFsc28gbWFrZXMgYXNz dW1wdGlvbnMgb24gdGhlIHBhdGggc2VsZWN0aW9uLg0KPj4NCj4+IFRoYW5rcywNCj4+IE1pcmph DQo+Pg0KPj4NCj4+DQo+Pj4gQW0gMjMuMDUuMjAxNyB1bSAxMzo0OSBzY2hyaWViIEppYXppIFlp IDxpZXRmQGppYXppeWkuY29tPG1haWx0bzppZXRmQGppYXppeWkuY29tPj46DQo+Pj4NCj4+PiBE ZWFyIE1pcmphLA0KPj4+DQo+Pj4gVGhhbmsgdmVyeSBtdWNoIGZvciB5b3VyIHJlcGx5Lg0KPj4+ DQo+Pj4gV2UgdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4gb24gdGhlIHBlcmZvcm1hbmNlLCBlc3Bl Y2lhbGx5IHRoZSBpc3N1ZSBvZiBwYWNrZXQgcmVvcmRlcmluZyB3aGVuIHRoZSBtdWx0aXBhdGgg cHJvdG9jb2wgaXMgYXBwbGllZCB0byB0cmFuc3BvcnQgcHJvdG9jb2wgbGlrZSBUQ1AuIFRoZXJl Zm9yZSwgd2UgcHJvcG9zZSB0byBoYXZlIHNvbWUgZ3VpZGVsaW5lcyB0byBpbmRpY2F0ZSB3aGVu IHBlci1mbG93IHNjaGVkdWxpbmcgaXMgcmVjb21tZW5kZWQsIGFuZCB3aGVuIHBlci1wYWNrZXQg c2NoZWR1bGluZyBpcyByZWNvbW1lbmRlZC4NCj4+Pg0KPj4+IE1vcmUgc3BlY2lmaWNhbGx5LCBp biB0aGUgZHJhZnQsIHdlIHByb3Bvc2UgdGhlIHRleHQ6DQo+Pj4NCj4+Pg0KPj4+ID09PT09PT09 PT0NCj4+PiBJbiBzZWN0aW9uIDEuMSwgRXhwZXJpbWVudHMgdG8gYmUgY29uZHVjdGVkOg0KPj4+ DQo+Pj4gICAgIOKAoiBEaWZmZXJlbnQgcGF0aC1zZWxlY3Rpb24gc2NoZWR1bGVycy4gRGVwZW5k aW5nIG9uIHRoZSBhcHBsaWNhdGlvbiB0eXBlIGFuZCB0cmFuc3BvcnQgbGF5ZXIgdHlwZSBlaXRo ZXIgcGVyLWZsb3cgc2NoZWR1bGVyIG9yIHBlci1kYXRhZ3JhbSBzY2hlZHVsZXIgaXMgYXBwbGll ZC4gQnkgZGVmYXVsdCwgcm91bmQtcm9iaW4gc2NoZWR1bGluZyBpcyB1c2VkIHRvIHNlbGVjdCBh IHBhdGggdG8gYmUgdXNlZC4gSW4gc29tZSBzY2VuYXJpb3MsIHdlaWdodGVkIHNjaGVkdWxpbmcg Y2FuIGJlIGNvbnNpZGVyZWQ6IGZvciBleGFtcGxlLCB0aGUgcGF0aHMgd2l0aCBsb3dlciBtZXRy aWNzIChpLmUuLCBoaWdoZXIgcXVhbGl0eSkgY2FuIHRyYW5zZmVyIG1vcmUgZGF0YWdyYW1zIG9y IGZsb3dzIGNvbXBhcmVkIHRvIHBhdGhzIHdpdGggaGlnaGVyIG1ldHJpY3MuDQo+Pj4NCj4+Pg0K Pj4+IEluIHNlY3Rpb24gOC40LCBEYXRhZ3JhbSBQcm9jZXNzaW5nIGF0IHRoZSBNUC1PTFNSdjIg T3JpZ2luYXRvcg0KPj4+DQo+Pj4gSWYgYSBtYXRjaGluZyBNdWx0aXBhdGggUm91dGluZyBUdXBs ZSBpcyBvYnRhaW5lZCwgdGhlIFBhdGggVHVwbGVzIG9mIHRoZSBNdWx0aXBhdGggUm91dGluZyBU dXBsZSBhcmUgYXBwbGllZCB0byB0aGUgZGF0YWdyYW1zIHVzaW5nIHJvdW5kLXJvYmluIHNjaGVk dWxpbmcuIFRoZSBzY2hlZHVsaW5nIHBvbGljeSBjYW4gYmUgZWl0aGVyIHBlci1mbG93IG9yIHBl ci1kYXRhZ3JhbSwgZGVwZW5kaW5nIG9uIHRoZSB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2wgYW5k IHRoZSBhcHBsaWNhdGlvbiB1c2VkOg0KPj4+DQo+Pj4gICAgIC0gSW4gcGVyLWZsb3cgc2NoZWR1 bGluZywgdGhlIGRhdGFncmFtcyBvZiB0aGUgc2FtZSBmbG93IGlzIHRyYW5zbWl0dGVkIHRocm91 Z2ggdGhlIHNhbWUgcGF0aC4gRGlmZmVyZW50IGZsb3dzIGFyZSBhc3NpZ25lZCB0byBkaWZmZXJl bnQgcGF0aHMgYWNjb3JkaW5nIHRvIHJvdW5kLXJvYmluIHNjaGVkdWxpbmcuIEZvciBleGFtcGxl LCB0aGVyZSBhcmUgMiBwYXRoIFR1cGxlcyAoUGF0aC0xLCBQYXRoLTIpIGZvciB0aGUgZGVzdGlu YXRpb24gcm91dGVyIEQuIEEgc2VyaWVzIG9mIGZsb3dzIChGbG93LTEsIEZsb3ctMiwgRmxvdy0z LCAuLi4gZXRjLikgYXJlIHRvIGJlIHNlbnQgdG8gcm91dGVyIEQuIFBhdGgtMSBpcyB0aGVuIGNo b3NlbiBmb3IgRmxvdy0xLCBQYXRoLTIgZm9yIEZsb3ctMiwgUGF0aC0xIGZvciBGbG93IDMsIGV0 Yy4NCj4+Pg0KPj4+ICAgICAtIEluIHBlci1kYXRhZ3JhbSBzY2hlZHVsaW5nLCBkaWZmZXJlbnQg ZGF0YWdyYW1zIGFyZSB0cmFuc21pdHRlZCB0aHJvdWdoIGRpZmZlcmVudCBwYXRocyBhY2NvcmRp bmcgdG8gcm91bmQtcm9iaW4gc2NoZWR1bGluZy4gRm9yIGV4YW1wbGUsIHRoZXJlIGFyZSAyIHBh dGggVHVwbGVzIChQYXRoLTEsIFBhdGgtMikgZm9yIHRoZSBkZXN0aW5hdGlvbiByb3V0ZXIgRC4g QSBzZXJpZXMgb2YgZGF0YWdyYW1zIChQYWNrZXQtMSwgUGFja2V0LTIsIFBhY2tldC0zLCAuLi4g ZXRjLikgYXJlIHRvIGJlIHNlbnQgdG8gcm91dGVyIEQuIFBhdGgtMSBpcyB0aGVuIGNob3NlbiBm b3IgUGFja2V0LTEsIFBhdGgtMiBmb3IgUGFja2V0LTIsIFBhdGgtMSBmb3IgUGFja2V0IDMsIGV0 Yy4NCj4+Pg0KPj4+IFBlci1mbG93IHNjaGVkdWxpbmcgaXMgcmVjb21tZW5kZWQgZm9yIHRyYW5z cG9ydCBsYXllciBwcm90b2NvbHMgdGhhdCByZXF1aXJlIHN0cmljdCBvcmRlcmluZyBvZiB0aGUg ZGF0YWdyYW1zIHN1Y2ggYXMgVENQLiBCeSBkZWZhdWx0LCBwZXItZmxvdyBzY2hlZHVsaW5nIGlz IHVzZWQuIFBlci1EYXRhZ3JhbSBzY2hlZHVsaW5nIGlzIHJlY29tbWVuZGVkIGZvciB0cmFuc3Bv cnQgbGF5ZXIgcHJvdG9jb2xzIHRoYXQgaGF2ZSBsZXNzIGNvbnN0cmFpbnQgb24gZGF0YWdyYW0g YXJyaXZpbmcgb3JkZXIgc3VjaCBhcyBVRFAuIEluIGxvc3N5IG5ldHdvcmtzLCBwZXItZGF0YWdy YW0gc2NoZWR1bGluZyBpcyBhbHNvIHJlY29tbWVuZGVkLg0KPj4+IE90aGVyIHBhdGggc2NoZWR1 bGluZyBtZWNoYW5pc21zIGFyZSBhbHNvIHBvc3NpYmxlIGFuZCB3aWxsIG5vdCBpbXBhY3QgdGhl IGludGVyb3BlcmFiaWxpdHkgb2YgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucy4NCj4+Pg0KPj4+ ID09PT09PT09PT09DQo+Pj4NCj4+PiBJZiBpdCBsb29rcyBnb29kIGZvciB5b3UsIHdlIHdpbGwg bWFrZSB0aGUgbW9kaWZpY2F0aW9uIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4N Cj4+Pg0KPj4+IHJlZ2FyZHMNCj4+Pg0KPj4+IEppYXppDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+IE9u IDIyIE1heSAyMDE3LCBhdCAxMjoxNywgTWlyamEgS3VlaGxld2luZCAoSUVURikgPGlldGZAa3Vl aGxld2luZC5uZXQ8bWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQ+PiB3cm90ZToNCj4+Pj4NCj4+ Pj4gSGkgSmlhemksDQo+Pj4+DQo+Pj4+IHNvcnJ5IGZvciBteSB2ZXJ5IGxhdGUgcmVwbHkuIFBs ZWFzZSBzZWUgYmVsb3cuDQo+Pj4+DQo+Pj4+PiBBbSAxMC4wNS4yMDE3IHVtIDAwOjUxIHNjaHJp ZWIgSmlhemkgWWkgPGlldGZAamlheml5aS5jb208bWFpbHRvOmlldGZAamlheml5aS5jb20+PjoN Cj4+Pj4+DQo+Pj4+PiBEZWFyIE1pcmphLA0KPj4+Pj4NCj4+Pj4+IFRoYW5rcyB2ZXJ5IG11Y2gg Zm9yIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy4gUGxlYXNlIGZpbmQgdGhlIHJlcGx5IGlubGlu ZToNCj4+Pj4+DQo+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+IERJU0NVU1M6DQo+Pj4+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+Pj4+DQo+Pj4+Pj4gVGhlIGZvbGxvd2luZyB0ZXh0IGluIHNlY3Rp b24gNCBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHNjaGVkdWxpbmcgaXMgZG9uZQ0KPj4+Pj4+IG9u IGEgcGVyLXBhY2tldCBiYXNpczoNCj4+Pj4+PiAiV2hlbiB0aGVyZSBpcyBhDQo+Pj4+Pj4gZGF0 YWdyYW0gdG8gYmUgc2VudCB0byBhIGRlc3RpbmF0aW9uLCB0aGUgc291cmNlIHJvdXRlciBhY3F1 aXJlcyBhDQo+Pj4+Pj4gcGF0aCBmcm9tIHRoZSBNdWx0aS1wYXRoIFJvdXRpbmcgU2V0IChNQVkg YmUgUm91bmQtUm9iaW4sIG9yIG90aGVyDQo+Pj4+Pj4gc2NoZWR1bGluZyBhbGdvcml0aG1zKS4i DQo+Pj4+Pj4gVGhpcyBzZWVtcyBub3QgYXBwcm9wcmlhdGUgYXMgZS5nLiBUQ1AgcGFja2V0cyBy b3V0ZWQgb24gbGlua3Mgd2l0aA0KPj4+Pj4+IGxhcmdlbHkgZGlmZmVyZW50IGRlbGF5cyBtYXkg c3VmZmVyIHBlcmZvcm1hbmNlLiBFQ01QIHVzdWFsbHkgaGFzaGVzIHRoZQ0KPj4+Pj4+IDUtdHVw bGUgb3IgNi10dXBsZSAoaW5jbC4gRGlmZlNlcnYgQ29kZXBvaW50KSB0byBzZXR1cCBzdGF0ZSBh bmQgcm91dGVzDQo+Pj4+Pj4gYWxsIHBhY2tldHMgYmVsb25naW5nIHRvIHRoZSBzYW1lIGZsb3cg b24gdGhlIHNhbWUgcm91dGUuIEkgcmVjb21tZW5kIHRvDQo+Pj4+Pj4gYXBwbHkgdGhlIHNhbWUg aGVyZS4NCj4+Pj4+Pg0KPj4+Pj4+IEFsc28gcmVsYXRlZCBpcyB0aGlzIHRleHQgaW4gc2VjdGlv biA4LjQgdGhhdCBzaG91bGQgZXhwbGFpbiBSb3VuZC1Sb2Jpbg0KPj4+Pj4+IG9uIGEgcGVyIGZs b3cgYmFzaXMgaW5zdGVhZC4gRnVydGhlciB0aGlzIHNob3VsZCBvbmx5IGJlIGFuIGV4YW1wbGUN Cj4+Pj4+PiBzY2hlZHVsaW5nIGFsb2dpcnRobSB3aGlsZSB0ZXh0IGJlbG9uZyBzZWVtcyB0byBh c3N1bWUgdGhhdCBSb3VuZC1Sb2Jpbg0KPj4+Pj4+IGlzIGFsd2F5cyB1c2VkLg0KPj4+Pj4+ICJJ ZiBhIG1hdGNoaW5nIE11bHRpLXBhdGggUm91dGluZyBUdXBsZSBpcyBvYnRhaW5lZCwgdGhlIFBh dGggVHVwbGVzDQo+Pj4+Pj4gb2YgdGhlIE11bHRpLXBhdGggUm91dGluZyBUdXBsZSBhcmUgYXBw bGllZCB0byB0aGUgZGF0YWdyYW1zIHVzaW5nDQo+Pj4+Pj4gUm91bmQtcm9iaW4gc2NoZWR1bGlu Zy4gIEZvciBleGFtcGxlLCB0aGVyZSBhcmUgMiBwYXRoIFR1cGxlcw0KPj4+Pj4+IChQYXRoLTEs IFBhdGgtMikgZm9yIGRlc3RpbmF0aW9uIHJvdXRlciBELiBBIHNlcmllcyBvZiBkYXRhZ3JhbXMN Cj4+Pj4+PiAoUGFja2V0LTEsIFBhY2tldC0yLCBQYWNrZXQtMywgLi4uIGV0Yy4pIGFyZSB0byBi ZSBzZW50IHJvdXRlciBELg0KPj4+Pj4+IFBhdGgtMSBpcyB0aGVuIGNob3NlbiBmb3IgUGFja2V0 LTEsIFBhdGgtMiBmb3IgUGFja2V0LTIsIFBhdGgtMSBmb3INCj4+Pj4+PiBQYWNrZXQgMywgZXRj LiAgT3RoZXIgcGF0aCBzY2hlZHVsaW5nIG1lY2hhbmlzbXMgYXJlIGFsc28gcG9zc2libGUNCj4+ Pj4+PiBhbmQgd2lsbCBub3QgaW1wYWN0IHRoZSBpbnRlcm9wZXJhYmlsaXR5IG9mIGRpZmZlcmVu dA0KPj4+Pj4+IGltcGxlbWVudGF0aW9ucy7igJ0NCj4+Pj4+DQo+Pj4+PiBJbiBmYWN0LCB0aGUg cGVyLXBhY2tldCBzY2hlZHVsaW5nIGlzIGFuIGludGVudGlvbmFsIGNob2ljZSBiZWNhdXNlOg0K Pj4+Pj4NCj4+Pj4+IDEuIFRoZSBhaW1lZCBzY2VuYXJpbyBpcyBtb2JpbGUgYWQgaG9jIG5ldHdv cmtzLCB3aGljaCBoYXZlIGhpZ2ggcGFja2V0IGxvc3MgYnkgbmF0dXJlLiBPbmUgb2YgdGhlIG1v c3QgaW1wb3J0YW50IHJlYXNvbnMgaXMgcm91dGUgZmFpbHVyZSBkdWUgdG8gbW9iaWxpdHkg4oCU IGluIHN1Y2ggY2FzZSwgaWYgYSBwZXItZmxvdyBzY2hlZHVsaW5nIGlzIGFwcGxpZWQsIHRoZSB3 aG9sZSBmbG93IHdpbGwgbG9zdC4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHdlIHNlbmQgdGhlIHBh Y2tldHMgaW4gZGlzam9pbnQgcGF0aHMgKG5vdCBuZWNlc3NhcmlseSBlcXVhbCBjb3N0KSwgd2Ug Y2FuIHN0aWxsIG1ha2UgdXNlIHBhcnRpYWwgaW5mb3JtYXRpb24gb2YgdGhlIGZsb3csIG9yIGV2 ZW4gcmVjb25zdHJ1Y3QgdGhlIGZsb3cgd2l0aCBlcmFzdXJlIGNvZGluZy4gVGhpcyBpcyBlc3Bl Y2lhbGx5IGludGVyZXN0aW5nIGZvciB2aWRlby9hdWRpbyBzdHJlYW1pbmcuDQo+Pj4+DQo+Pj4+ IFRoaXMgaXMgb25seSB0cnVlIGZvciB1bnJlbGlhYmxlIG9yIHBhcnRpYWxseSByZWxpYWJsZSB0 cmFmZmljLiBJIHNlZSB5b3VyIHVzZSBjYXNlLiBIb3dldmVyLCB3aWxsIGlmIHlvdSBoYXZlIFRD UCB0cmFmZmljLCB5b3UgY2FuIHByb2JhYmx5IGFzc3VtZSB0aGF0IHRoZSB0cmFmZmljIGlzIHJl bGlhYmxlIGFuZCBzaG91bGQgbm90IHJvdXRlIG9uIGEgcGVyLXBhY2tldCBiYXNpcy4gVGhpcyBj YXNlIGlzIG5vdCBjb3ZlcmVkIGluIHlvdXIgZHJhZnQuIEFsc28gZm9yIG90aGVyIG5vbi1UQ1Ag eW91IG9mdGVuIG1pZ2h0IG5vdCBrbm93IG11Y2ggYWJvdXQgdGhlIHRyYWZmaWMgY2hhcmFjdGVy aXN0aWNzIGFuZCB0aGVyZWZvcmUgY2Fubm90IGtub3cgaWYgcGVyLXBhY2tldCBzY2hlZHVsaW5n IGlzIGdvb2Qgb3IgYmFkLiBUaGVyZWZvcmUgZGVmYXVsdCBzaG91bGQgYmUgcGVyLWZsb3cuDQo+ Pj4+DQo+Pj4+Pg0KPj4+Pj4gMi4gSW4gc3VjaCBraW5kIG9mIGxvc3N5IG5ldHdvcmtzLCB0aGUg dHJhZGl0aW9uYWwgVENQIHBlcmZvcm1zIHZlcnkgcG9vciBbMV0uIFNvIGFzIGZhciBhcyBJIGtu b3csIFRDUCBpcyBub3QgdmVyeSBwb3B1bGFyIGluIGFkIGhvYyBuZXR3b3Jrcy4gT24gdGhlIG90 aGVyIGhhbmQsIGJhc2VkIG9uIG91ciBzdHVkeSwgdGhlIG11bHRpLXBhdGggcm91dGluZyBjYW4g YWN0dWFsbHkgcmVkdWNlIHRoZSBvdmVyYWxsIGppdHRlciBbMl0uDQo+Pj4+DQo+Pj4+IEkgZGlk buKAmXQgaGF2ZSB0aW1lIHRvIHJlYWQgdGhlIHdob2xlIHBhcGVyIGJ1dCBvbiBhIGJyaWVmIGxv b2ssIGl0IGxvb2tzIGxpa2UgeW91IHRha2UgdGhlIGRlbGF5IGludG8gYWNjb3VudCBmb3IgVENQ IHRyYWZmaWMuIFdoaWNoIGlzIHdoYXQgSSBzYWlkIGFib3ZlOiBlaXRoZXIgeW91IGhhdmUgdHdv IGxpbmtzIHdoaWNoIGhhdmUgbW9yZSBvciBsZXNzIHRoZSBzYW1lIGRlbGF5IG9yIHJlLW9yZGVy aW5nIHdpbGwgYmUgd3JvbmdseSBpbnRlcnByZXRlZCBhcyBjb25nZXN0aW9uLiBUaGUgb3RoZXIg cHJvYmxlbSBpcyBUQ1AgcmVkdWNlcyBpdHMgc2VuZGluZyByYXRlIGR1ZSB0byBsb3NzLiBTbyBp ZiBib3RoIGxpbmtzIGFyZSBjb25nZXN0ZWQgYW5kIGxvc3NlcyBvY2N1cnJlZCAoaW4gYSBub24t c3luY2hyb25pemVkIHdheSksIFRDUCB3aWxsIHJlYWN0IHRvIGJvdGggc2lnbmFscyBhbmQgcmVk dWNlIGl0cyBzZW5kaW5nIHJhdGUgbW9yZSB0aGFuIG5lY2Vzc2FyeS4gVGhhdCdzIHdoeSBJIHdv dWxkIHJlY29tbWVuZCB0byBzY2hlZHVsZSBUQ1AgYXMgd2VsbCBhcyBvdGhlciByZWxpYWJsZSBh bmQgY29uZ2VzdGlvbi1jb250cm9sbGVkIHRyYWZmaWMgb24gYSBwZXItZmxvdyBiYXNlLiBGdXJ0 aGVyIGZvciBVRFAgdHJhZmZpYyB0aGVyZSBpcyBubyBnb29kIHdheSB0byBhY3R1YWxseSBrbm93 IGlmIHRoZSB0cmFmZmljIGlzIHJlbGlhYmx5IHRyYW5zbWl0dGVkIGFuZCBjb25nZXN0aW9uIGNv bnRyb2wsIHNvIGl04oCZcyBoYXJkIHRvIG1ha2Ugc3VjaCBhIGRlY2lzaW9uIGluIHRoZSBuZXR3 b3JrIGluIGEgZ2VuZXJhbCBjYXNlLg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IFdlIHVuZGVyc3RhbmQg eW91ciBjb25jZXJuIG9uIHRoaXMgaXNzdWUgKGFuZCB5b3UgY2FuIGltYWdpbmUgdGhhdCB5b3Ug YXJlIG5vdCB0aGUgZmlyc3Qgb25lIHdobyByYWlzZXMgdGhpcyA7KS4gSXQgaXMgYWxzbyBzb21l dGhpbmcgdGhhdCB3ZSB3YW50IHRvIGhhdmUgZnVydGhlciBleHBlcmllbmNlIGZyb20gdGhpcyAq ZXhwZXJpbWVudGFsKiBkcmFmdCwgYXMgd2Ugc3RhdGVkIGluIHRoZSDigJxleHBlcmltZW50cyB0 byBiZSBjb25kdWN0ZWTigJ0gc2VjdGlvbjoNCj4+Pj4+DQo+Pj4+PiAgIOKAoiBEaWZmZXJlbnQg cGF0aC1zZWxlY3Rpb24gc2NoZWR1bGVycy4gQnkgZGVmYXVsdCwgcm91bmQtcm9iaW4gc2NoZWR1 bGluZyBpcyB1c2VkIHRvIHNlbGVjdCBhIHBhdGggdG8gYmUgdXNlZCBmb3IgZGF0YWdyYW1zLiBJ biBzb21lIHNjZW5hcmlvcywgd2VpZ2h0ZWQgc2NoZWR1bGluZyBjYW4gYmUgY29uc2lkZXJlZDog Zm9yIGV4YW1wbGUsIHRoZSBwYXRocyB3aXRoIGxvd2VyIG1ldHJpY3MgKGkuZS4sIGhpZ2hlciBx dWFsaXR5KSBjYW4gdHJhbnNmZXIgbW9yZSBkYXRhZ3JhbXMgY29tcGFyZWQgdG8gcGF0aHMgd2l0 aCBoaWdoZXIgbWV0cmljcy4NCj4+Pj4+ICAg4oCiIFRoZSBpbXBhY3RzIG9mIHRoZSBkZWxheSB2 YXJpYXRpb24gZHVlIHRvIG11bHRpcGF0aCByb3V0aW5nLiBbUkZDMjk5MV0gYnJpbmdzIG91dCBz b21lIGNvbmNlcm5zIG9mIG11bHRpcGF0aCByb3V0aW5nLCBlc3BlY2lhbGx5IHZhcmlhYmxlIGxh dGVuY2llcy4gQWx0aG91Z2ggY3VycmVudCBleHBlcmltZW50IHJlc3VsdHMgc2hvdyB0aGF0IG11 bHRpcGF0aCByb3V0aW5nIGNhbiByZWR1Y2UgdGhlIGppdHRlciBpbiBkeW5hbWljIHNjZW5hcmlv cywgc29tZSB0cmFuc3BvcnQgcHJvdG9jb2xzIG9yIGFwcGxpY2F0aW9ucyBtYXkgYmUgc2Vuc2l0 aXZlIHRvIHRoZSBkYXRhZ3JhbSByZS1vcmRlcmluZy4NCj4+Pj4+ICAg4oCiIFRoZSBkaXNqb2lu dCBtdWx0aXBhdGggcHJvdG9jb2wgaGFzIGludGVyZXN0aW5nIGFwcGxpY2F0aW9uIHdpdGggZXJh c3VyZSBjb2RpbmcsIGVzcGVjaWFsbHkgZm9yIHNlcnZpY2VzIGxpa2UgdmlkZW8vYXVkaW8gc3Ry ZWFtaW5nIFtXUE1DMTFdLiBUaGUgY29tYmluYXRpb24gb2YgZXJhc3VyZSBjb2RpbmcgbWVjaGFu aXNtcyBhbmQgdGhpcyBleHRlbnNpb24gaXMgdGh1cyBlbmNvdXJhZ2VkLg0KPj4+Pg0KPj4+PiBU aGF04oCZcyBmaW5lIGJ1dCB0aGVuIHlvdSBjYW5ub3QgYXNzdW1lIGluIHRoZSByZXN0IG9mIHRo ZSBkb2N1bWVudCB0aGF0IHBlci1wYWNrZXQgc2NoZWR1bGluZyBpcyB1c2VkLg0KPj4+Pg0KPj4+ PiBUaGVyZSBhcmUgdHdvIG9wdGlvbnMgdG8gaGFuZGxlIHRoaXM6IGVpdGhlciB5b3UgcmVtb3Zl IHRoZSB0ZXh0IHRoYXQgaXMgY2l0ZWQgYWJvdmUgYW5kIGRvIG5vdCB0YWxrIGFib3V0IHNjaGVk dWxpbmcgYXQgYWxsIG90aGVyIHRoYW4gaW4gdGhlIGV4cGVyaW1lbnRhdGlvbiBwYXJ0LCBvciB5 b3UgZXhwbGFpbiBjYXJlZnVsbHkgd2hlbiBwb3RlbnRpYWxseSBwZXItcGFja2V0IHNjaGVkdWxp bmcgY291bGQgYmUgdXNlZCBhbmQgbWFrZSBjbGVhciB0aGF0IGJ5IGRlZmF1bHQgYW5kIGVzcGVj aWFsbHkgZm9yIFRDUCBwZXItZmxvdyBzY2hlZHVsaW5nIHNob3VsZCBiZSB1c2VkLg0KPj4+Pg0K Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBbMV0gUGVyZm9ybWFuY2UgRXZhbHVhdGlvbiBvZiBU Q1Agb3ZlciBNb2JpbGUgQWQtaG9jIE5ldHdvcmtzIGh0dHBzOi8vYXJ4aXYub3JnL3BkZi8xMDAy LjIxODkucGRmPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fYXJ4aXYub3JnX3BkZl8xMDAyLjIxODkucGRmJmQ9RHdNRmFRJmM9TGxVdmlkdmxoU3RH VVN4UWwwZ2lPQSZyPVF6Z0NLbEstZVVzYkxXNXI4S1pBTDlMX3lxTk9OMWRiS3RNYS1XYnhuYTgm bT1kamU3bVFZSWlGRGpnYkpLOG1WcHdpTDk2emcybTk5THFzM21WUUdwRWZrJnM9a1ZyazU5Zktr Y0wxVjdRcjdMOWdsbkdROXlDaHdXU1hoajBhQ05GbjJkbyZlPT4NCj4+Pj4+IFsyXSBNdWx0aXBh dGggb3B0aW1pemVkIGxpbmsgc3RhdGUgcm91dGluZyBmb3IgbW9iaWxlIGFkIGhvYyBuZXR3b3Jr cyIsIEluIEVsc2V2aWVyIEFkIEhvYyBKb3VybmFsLCB2b2wuOSwgbi4gMSwgMjgtNDcsIEphbnVh cnksIDIwMTEuDQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gUmVsYXRlZCBpcyB0aGlzIHRleHQgaW4g c2VjdGlvbiA4LjQuOg0KPj4+Pj4+ICJJZiBkYXRhZ3JhbXMgd2l0aG91dCBzb3VyY2Ugcm91dGlu ZyBoZWFkZXIgbmVlZCB0byBiZSBmb3J3YXJkZWQgdXNpbmcNCj4+Pj4+PiBtdWx0aXBsZSBwYXRo cyAoZm9yIGV4YW1wbGUsIGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiBvZiBEaWZmU2Vydg0KPj4+ Pj4+IENvZGUgUG9pbnQgW1JGQzI0NzRdKSINCj4+Pj4+PiBSRkMyNDc0IGRvZXMgbm90IHNwZWNp ZnkgYW55IGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50cyBvbiBtdWx0aXBhdGggdXNlDQo+Pj4+Pj4g YW5kIGFzIHN1Y2ggdGhlIERpZmZTZXJ2ZSBmaWVsZCBzaG91bGQgbm90IGJlIHVzZWQgdG8gZGV0 ZXJtaW5lIGlmIHRoZQ0KPj4+Pj4+IGZsb3cgY2FuIGJlIHJvdXRlZCBvbiBtdWx0aXBsZSBwYXRo cy4gVGhlIGFiaWxpdHkgdG8gcHJvZml0IGZyb20NCj4+Pj4+PiBtdWx0aXBhdGggcm91dGluZyBk ZXBlbmRzIG5vdCBvbmx5IG9uIHRoZSBhcHBsaWNhdGlvbiBhbmQgcHJvdG9jb2xzIHVzZWQNCj4+ Pj4+PiBidXQgYWxzbyBvbiB0aGUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBtdWx0aXBhdGggbGlu ayhzKTsgc28gaXQncyBoYXJkIHRvDQo+Pj4+Pj4gbWFrZSBhbnkgaW1wbGljaXQgYXNzdW1wdGlv bnMgaGVyZS4gSG93ZXZlciwgaWYgcm91dGluZyB3b3VsZCBvbmx5IGJlDQo+Pj4+Pj4gcmVjb21t ZW5kZWQgb24gYSBwZXItZmxvdyBiYXNpcyB0aGlzIHByb2JsZW0gZG9lcyBub3Qgb2NjdXIgYW5k IHRoZQ0KPj4+Pj4+IGJyYWNrZXRzIGFib3ZlIGNvdWxkIGJlIHJlbW92ZS4gRnVydGhlciwgaWYg cm91dGVkIG9uIGEgcGVyIGZsb3cgYmFzaXMNCj4+Pj4+PiB3b3VsZCBiZSBkb25lLCBEaWZmU2Vy diBjb3VsZCBhY3R1YWxseSBiZSB1c2VkIHRvIGRlY2lkZSB3aGljaCBwYXRoIHRvDQo+Pj4+Pj4g dXNlLCBpZiBlLmcuIG9uZSBwYXRoIGhhcyBhIGxvd2VyIGRlbGF5LCBidXQgdGhhdCBzZWVtIHRv IG5lZWQgZnVydGhlcg0KPj4+Pj4+IGRpc2N1c3Npb24gYXMgd2VsbC4NCj4+Pj4+DQo+Pj4+PiBB cyB3ZSBtZW50aW9uZWQgYmVmb3JlLCB0aGUgbXVsdGlwYXRoIHJvdXRpbmcgaGFzIHNwZWNpYWwg aW50ZXJlc3RzIGluIGF1ZGlvL3ZpZGVvIHN0cmVhbWluZyBhcHBsaWNhdGlvbnMuIEZvciBhcHBs aWNhdGlvbnMgdGhhdCByZXF1aXJlcyBzdHJpY3Qgb3JkZXJpbmcsIHNpbmdsZSBwYXRoIGNhbiBi ZSB1c2VkLiBGb3Igc3RyZWFtaW5nIGFuZCB0aW1lLWNyaXRpY2FsIGFwcGxpY2F0aW9ucywgdGhl IG11bHRpLXBhdGggYXBwbGljYXRpb24gbWlnaHQgYmUgbW9yZSBpbnRlcmVzdGluZywgd2hpY2gg Y2FuIGJlIGlkZW50aWZpZWQgYnkgdGhlIERpZmZTZXJ2ZSBpbmZvcm1hdGlvbi4NCj4+Pj4NCj4+ Pj4gV2hpY2ggRGlmZlNlcnYgY29kZXBvaW50cyBhcmUgeW91IHRha2luZyBhYm91dD8gU29tZSBv ZiB0aGUgY29kZSBwb2ludHMgcmVxdWlyZSBsb3cgZGVsYXkgYnV0IHRoZXkgZWl0aGVyIHNheSBu b3RoaW5nIGFib3V0IHJlb3JkZXJpbmcgb3IgcmVxdWlyZSBhIGJvdW5kZWQgaml0dGVyIGFzIHdl bGwgd2hpY2ggbWVhbiBmb3J3YXJkaW5nIG9uIGEgcGVyLXBhY2tldCBiYXNpcyBvdmVyIHR3byBs aW5rcyB3aGljaCBoaWdobHkgZGlmZmVyZW50IGRlbGF5cyBzaG91bGQgbm90IGJlIGRvbmUuDQo+ Pj4+DQo+Pj4+IE1pcmphDQo+Pj4+DQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pj4gQ09NTUVOVDoNCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4+Pj4NCj4+Pj4+PiBNaW5vciBjb21tZW50cy9xdWVzdGlvbnM6DQo+Pj4+Pj4NCj4+Pj4+PiAx KSBzZWN0aW9uIDguNDogdGhpcyBzZW50ZW5jZSBpcyBub3QgY2xlYXI6DQo+Pj4+Pj4gIkl0IGlz IFJFQ09NTUVOREVEIHRvIHVzZSBNVFUgc2l6ZXMgY29uc2lkZXJpbmcgdGhlIHNvdXJjZSByb3V0 aW5nDQo+Pj4+Pj4gaGVhZGVyIHRvIGF2b2lkIGZyYWdtZW50YXRpb24uIg0KPj4+Pj4+IE1BWUJF DQo+Pj4+Pj4gIkl0IGlzIE5PVCBSRUNPTU1FTkRFRCB0byBmcmFnbWVudCB0aGUgSVAgcGFja2V0 IGlmIHRoZSBwYWNrZXQgd2l0aCB0aGUNCj4+Pj4+PiBzb3VyY2Ugcm91dGluZyBoZWFkZXIgd291 bGQgIGV4Y2VlZCB0aGUgbWluaW11bSBNVFUgYWxvbmcgdGhlIHBhdGguIEluDQo+Pj4+Pj4gdGhp cyBjYXNlIHNvdXJjZSByb3V0aW5nIGFuZCB0aGVyZWZvcmUgdGhlIGFkZGl0aW9uYWwgcGF0aCBj YWxjdWxhdGVkIGJ5DQo+Pj4+Pj4gTVAtT0xTUnYyIFNIT1VMRCBOT1QgYmUgdXNlZC7igJ0NCj4+ Pj4+DQo+Pj4+PiBGaXhlZC4NCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAyKSBzZWN0aW9uIDk6DQo+ Pj4+Pj4gIkZvciBJUHY2IG5ldHdvcmtzLCBpdCBNVVNUDQo+Pj4+Pj4gICBiZSBzZXQgdG8gMCwg aS5lLiwgbm8gY29uc3RyYWludCBvbiBtYXhpbXVtIG51bWJlciBvZiBob3BzLiINCj4+Pj4+PiBX aHkgaXMgdGhhdD8NCj4+Pj4+DQo+Pj4+PiBCZWNhdXNlIHRoZSBjdXJyZW50IFJGQzY1NTQgc3Vw cG9ydHMgb25seSBJUHY2IHN0cmljdCBzb3VyY2Ugcm91dGluZywgd2UgdGh1cyBuZWVkIHRvIGtl ZXAgYWxsIHRoZSBwYXRoIGluZm9ybWF0aW9uIGluIHRoZSBzb3VyY2Ugcm91dGluZyBoZWFkZXIs IGluIHdoaWNoIGNhc2Ugd2UgZG9u4oCZdCBrbm93IHRoZSBudW1iZXIgb2YgaG9wcy4NCj4+Pj4+ DQo+Pj4+PiBPbiB0aGUgb3RoZXIgaGFuZCwgd2Ugbm90aWNlZCB0aGF0IHRoZSBJUHY2IHNlZ21l bnQgcm91dGluZyBoZWFkZXIgaXMgYmVpbmcgZGlzY3Vzc2VkIGF0IDZtYW4sIHdlIHRodXMgaGF2 ZSB0aGUgZm9sbG93aW5nIHRleHQgaW4gdGhlIOKAnEV4cGVyaW1lbnRzIHRvIGJlIGNvbmR1Y3Rl ZOKAnSBzZWN0aW9uOg0KPj4+Pj4NCj4+Pj4+ICAg4oCiIFVzZSBvZiBJUHY2IGxvb3NlIHNvdXJj ZSByb3V0aW5nLiBJbiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uLCBvbmx5IHN0cmljdCBzb3Vy Y2Ugcm91dGluZyBpcyB1c2VkIGZvciBJUHY2IGJhc2VkIG9uIFtSRkM2NTU0XS4gSW4gW0nigJFE LmlldGbigJE2bWFu4oCRc2VnbWVudOKAkXJvdXRpbmfigJFoZWFkZXJdLCB0aGUgdXNlIG9mIGxv b3NlIHNvdXJjZSByb3V0aW5nIGlzIGFsc28gcHJvcG9zZWQgaW4gSVB2Ni4gSW4gc2NlbmFyaW9z IHdoZXJlIHRoZSBsZW5ndGggb2YgdGhlIHNvdXJjZSByb3V0aW5nIGhlYWRlciBpcyBjcml0aWNh bCwgdGhlIGxvb3NlIHNvdXJjZSByb3V0aW5nIGNhbiBiZSBjb25zaWRlcmVkLg0KPj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+IDMpIE5vdCBzdXJlIHdoeSBzZWN0aW9uIDEyLjEuIGlzIHRoZXJlPyBDYW4g dGhpcyBiZSByZW1vdmVkPw0KPj4+Pj4NCj4+Pj4+IFJlbW92ZWQuDQo+Pj4+Pg0KPj4+Pj4gQWdh aW5zLCB3ZSBhcHByZWNpYXRlIHlvdXIgdmFsdWFibGUgY29tbWVudHMgYW5kIGhvcGUgdGhhdCBv dXIgcmVwbHkgYWRkcmVzc2VzIHlvdXIgY29uY2Vybi4NCj4+Pj4+DQo+Pj4+PiByZWdhcmRzDQo+ Pj4+Pg0KPj4+Pj4gSmlhemkNCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbWFuZXQgbWFp bGluZyBsaXN0DQo+Pj4+Pj4gbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0K Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19tYW5ldCZkPUR3TUZhUSZjPUxsVXZpZHZsaFN0R1VTeFFsMGdp T0Emcj1RemdDS2xLLWVVc2JMVzVyOEtaQUw5TF95cU5PTjFkYkt0TWEtV2J4bmE4Jm09ZGplN21R WUlpRkRqZ2JKSzhtVnB3aUw5NnpnMm05OUxxczNtVlFHcEVmayZzPUpoZDlwVjBDd193WEtibmxG c3RWWklDS3ZtVEh6X0Z6NUcxQXlqWXZrc0kmZT0+DQo+Pj4NCj4+DQo+DQo+DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxp c3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19t YW5ldCZkPUR3TUZhUSZjPUxsVXZpZHZsaFN0R1VTeFFsMGdpT0Emcj1RemdDS2xLLWVVc2JMVzVy OEtaQUw5TF95cU5PTjFkYkt0TWEtV2J4bmE4Jm09ZGplN21RWUlpRkRqZ2JKSzhtVnB3aUw5Nnpn Mm05OUxxczNtVlFHcEVmayZzPUpoZDlwVjBDd193WEtibmxGc3RWWklDS3ZtVEh6X0Z6NUcxQXlq WXZrc0kmZT0+DQoNCgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpUaGlzIGVsZWN0cm9uaWMg bWVzc2FnZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMKaW5mb3Jt YXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnkK YW5kL29yIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsCm9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYg eW91IGFyZSBub3QgdGhlIG9yaWdpbmFsCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNp YmxlIGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGUKaW50ZW5kZWQgcmVjaXBpZW50LCBi ZSBhZHZpc2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgYW5k IHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9yCmNv cHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRpYXRlbHkg bm90aWZ5IHRoZSBzZW5kZXIuCg== --_000_b72836e7c79044189181bd5a2fa7995aVAUSDITCHM2idirectnet_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFCLA0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgdGV4dCB5b3UgcmVmZXJlbmNlIGluIFNlY3Rpb24g OC40IGlzIHRhbGtpbmcgYWJvdXQgdGhlIGRhdGEgYmVpbmcgcm91dGVkOyBub3QgYWJvdXQgdGhl IGNvbnRyb2wgcGxhbmUgKE9MU1IpIHRyYWZmaWMuIEZvciBleGFtcGxlLCBpZiByZWd1bGFyIGJy b3dzZXIgdHJhZmZpYw0KIHdlcmUgdG8gYmUgY2FycmllZCBieSBhbiBPTFNSIG5ldHdvcmsgd2l0 aCB0aGUgbXVsdGlwYXRoIGVuaGFuY2VtZW50LCBzYWlkIGJyb3dzZXIgdHJhZmZpYyAod2hpY2gg aXMgVENQLWJhc2VkKSBNVVNUIGJlIGRlbGl2ZXJlZCBieSB0aGUgbmV0d29yayBpbi1zZXF1ZW5j ZS4gVGhlIHJlc3RyaWN0aW9uIHN0YXRlZCBpbiBTZWN0aW9uIDguNCBwcmVzZXJ2ZXMgdGhlIG9y ZGVyaW5nLCBzaW5jZSB0aGUgdHJhZmZpYyBmb2xsb3dzIHRoZSBzYW1lIHBhdGguDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFzIHRvIFJGQzU0NDQg4oCTIElJ UkMsIHRoZSBXRyBkZWNpc2lvbiBhdCB0aGUgdGltZSB3YXMgdG8gYWxsb3cgZm9yIGJvdGggb3Bl cmF0aW9uIHVzaW5nIFVEUCBhcyBhIHRyYW5zcG9ydCBiZXR3ZWVuIHJvdXRlcnMsIGFzIHdlbGwg YXMgZm9yIExheWVyIDMgY29tbXVuaWNhdGlvbg0KIChhcyBPU1BGIGRvZXMpLiBUaGUgZGVjaXNp b24gb2Ygd2hldGhlciB0byBzdXBwb3J0IFVEUCBjb21tdW5pY2F0aW9uIG9yIExheWVyIDMgY29t bXVuaWNhdGlvbiBpcyBpbXBsZW1lbnRhdGlvbi1kZXBlbmRlbnQuIEFGQUlLLCB0aGVyZSBhcmUg bm8gTGF5ZXIgMyBpbXBsZW1lbnRhdGlvbnMgcHJlc2VudGx5LCBidXQgaWYgYW55b25lIG9uIHRo ZSBsaXN0IGtub3dzIG9mIG9uZSwgcGxlYXNlIGNvcnJlY3QgbWUuIEhvd2V2ZXIsIHRoYXQgaXMg dGhlDQogcmVhc29uIGJvdGggYSBVRFAgcG9ydCBudW1iZXIgYW5kIGFuIElQIG51bWJlciB3ZXJl IGFsbG9jYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN0YW4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1hbmV0IFttYWlsdG86 bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWJkdXNzYWxhbSBC YXJ5dW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMjYsIDIwMTcgMTE6NTIgQU08YnI+ DQo8Yj5Ubzo8L2I+IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpICZsdDtpZXRmQGt1ZWhsZXdpbmQu bmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gbWFuZXQgJmx0O21hbmV0QGlldGYub3JnJmd0OzsgVGhl IElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0 aXBhdGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTWlyamEgS8O8 aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGlwYXRoLTEy OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWlyamEsIGFuZCBJRVNHLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgZmly c3QgbWVudGlvbmVkIFRDUCBvciByZWxpYWJpbGl0eSZuYnNwO2luIHlvdXIgZmlyc3QgbWVzc2Fn ZSBhbmQgYXV0aG9ycyByZXBseWluZyB0b28sIGJ1dCBJTU8sIGluIE1BTkVUIFdHIGRyYWZ0cyB1 bmRlciBJRVRGJm5ic3A7d2Ugc3RpbGwgaGF2ZSBubyByb3V0aW5nIHRocm91Z2ggVENQIGJlY2F1 c2Ugb3VyIE1BTkVULVBhY2tldCBhcyBpbiBSRkM1NDQ0LCBpcyBvbmx5IGhhdmluZyBhcyBtZW50 aW9uZWQgaW4gUkZDNTQ5OA0KIHRoZSBJUCBudW1iZXIgMTM4IGFuZCB0aGUgVURQIHBvcnQgbnVt YmVyLiBTbyBvdXIgT0xTUnYyIHJvdXRlcnMgZG9uJ3QgZG8mbmJzcDthbnkgVENQIHBvcnRzLiBS ZWdhcmRpbmcgcmVsaWFiaWxpdHksIEkgZG9uJ3QgdGhpbmsgaXQgaXMgcmlnaHQgdG8gbWVudGlv biB0aGUgcmVsaWFiaWxpdHkgaW4gTUFORVQvdGhpcy1kcmFmdCwgYmVjYXVzZSBpdCBtYXkgbmVl ZCBtYW55IG90aGVyIGNvbnNpZGVyYXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBjbGFyaWZ5 IGluIHRoaXMgJm5ic3A7ZHJhZnQgdGhlIG1hbmV0IHBhY2tldCByZmM1NDQ0LCBhbmQgdGhhdCBp dCB0YWtlcyB0aGUgbWFuZXQgbWVzc2FnZXMgaW5jbHVkaW5nIHRoZSBtdWx0aXBhdGhzLiBTbyBp biB0aGUgZHJhZnQgbWVudGlvbnMgZGF0YWdyYW0sIGJ1dCBub3QgbWFuZXQgcGFja2V0IHdoaWNo IGlzIDU0NDQgcGFja2V0LCBpcyBvdXIgc291cmNlIHJvdXRpbmcNCiBhdCBpcCBsYXllciBvciB0 cmFuc3BvcnQgbGF5ZXIgZG8gd2UgbmVlZCBpcCBudW1iZXIgb3IgdHJhbnNwb3J0IHBvcnQgbnVt YmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZSBuZWVkIHRvIGFkZCB0aGUgYmVsb3cgdG8gc2VjdGlvbiAxMiBhcyBpdCB3YXMgZG9uZSBp biByZmM3MTgxIGFuZCA3NzIyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5FeHBlcnQgUmV2aWV3OiBFdmFsdWF0aW9uIEd1aWRlbGluZXM6PGJy Pg0KJm5ic3A7Jm5ic3A7IEZvciB0aGUgcmVnaXN0cnkgd2hlcmUgYW4gRXhwZXJ0IFJldmlldyBp cyByZXF1aXJlZCwgdGhlIGRlc2lnbmF0ZWQ8YnI+DQombmJzcDsmbmJzcDsgZXhwZXJ0IFNIT1VM RCB0YWtlIHRoZSBzYW1lIGdlbmVyYWwgcmVjb21tZW5kYXRpb25zIGludG88YnI+DQombmJzcDsm bmJzcDsgY29uc2lkZXJhdGlvbiBhcyBhcmUgc3BlY2lmaWVkIGJ5IFtSRkM1NDQ0XSwgW1JGQzU0 OThdLCBbUkZDNzYzMV0gYW5kJm5ic3A7W1JGQzc3MjJdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRyYWZ0IGlzIHVzaW5nIHRoZSBz YW1lIGhlYWRlciB0eXBlIG9mIHJmYzY1NTQgd2hpY2ggSSBtYXkgZGlzYWdyZWUuIEZ1cnRoZXJt b3JlLCBpbiBSRkM2NTU0IHJvdXRpbmcgaGFzIG1lbnRpb25lZCBpbiBpdHMgSUFOQSBzZWN0aW9u IHRoZSBhc3NpZ25lZCBpcHY2IG51bWJlciBpcyAzIGZvciBSUEwgc291cmNlIHJvdXRpbmcgKHRo aXMgZHJhZnQgaXMgbm90IGZvciBSUEwpLCBzbyBmb3IgdGhpcyBtdWx0aXBhdGgtcHJvdG9jb2ws DQogd2UgbmVlZCB0byBhc3NpZ24gYW4gSVB2NCBudW1iZXIgZm9yIHRoZSBtYW5ldC1zb3VyY2Ut cm91dGluZywmbmJzcDthbmQgJm5ic3A7d2Ugc2hvdWxkIG1lbnRpb24gaXQgaW4gc2VjdGlvbiAx MiBhcyB1c2luZyAxMzggZm9yIElQdjYgZm9yIG1hbmV0IHBhY2tldHMgNTQ0NC4gQXMgd2UgaGF2 ZSBkb25lIGluIE1BTkVUIERTUiBzb3VyY2Ugcm91dGluZyBSRkM0NzI4IGFzc2lnbmVkIGl0IGZv ciBJUHY0IG51bWJlciA0OC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc2VjdGlvbiAxMiB3ZSBuZWVkIHRvIHVwZGF0ZSB0aGUg dGFibGUgLTEgdG8gaGF2ZSBhIHRpdGxlIHNpbWlsYXIgdG8gNzcyMiB3aGljaCBpczo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHlwZSA3IE1l c3NhZ2UgVExWIFR5cGUgRXh0ZW5zaW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ob3dldmVyLCBhbmQgdGhhdCB3ZSBhZGQgdGhlIHJlZmVy ZW5jZXMgYW5kIHR5cGUgZXh0ZW5zaW9ucyBvZiAwIGFuZCAxIHdoaWNoIHdlcmUgYWxsb2NhdGVk IGFscmVhZHkuJm5ic3A7QWRkIHJlZmVyZW5jZXMgaW4gdGFibGUgMSBhcyA3MTgxIGFuZCA3NzIy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 YWtlIGNhcmUsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFCPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWF5IDI0LCAyMDE3IGF0 IDE6MjIgUE0sIE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpICZsdDs8YSBocmVmPSJtYWlsdG86aWV0 ZkBrdWVobGV3aW5kLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAa3VlaGxld2luZC5uZXQ8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MhIFRoYXTigJlzIG11Y2ggYmV0dGVyITxicj4NCjxicj4NClR3byBuaXRzIGJl bG93Ljxicj4NCjxicj4NCk1pcmphPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBBbSAyNC4wNS4yMDE3 IHVtIDAwOjI2IHNjaHJpZWIgSmlhemkgWWkgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGppYXpp eWkuY29tIj5pZXRmQGppYXppeWkuY29tPC9hPiZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkg TWlyamEsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBpbnB1 dC4gTm93IHdlIGhhdmUgdGhlIHRleHQgZm9yIHNlY3Rpb24gOC40Ojxicj4NCiZndDs8YnI+DQom Z3Q7Jmd0OyBJZiBhIG1hdGNoaW5nIE11bHRpcGF0aCBSb3V0aW5nIFR1cGxlIGlzIG9idGFpbmVk LCB0aGUgUGF0aCBUdXBsZXMgb2YgdGhlIE11bHRpcGF0aCBSb3V0aW5nIFR1cGxlIGFyZSBhcHBs aWVkIHRvIHRoZSBkYXRhZ3JhbXMgdXNpbmcgZWl0aGVyIHBlci1mbG93IHNjaGVkdWxpbmcgb3Ig cGVyLWRhdGFncmFtIHNjaGVkdWxpbmcsIGRlcGVuZGluZyBvbiB0aGUgdHJhbnNwb3J0IGxheWVy IHByb3RvY29sIGFuZCB0aGUgYXBwbGljYXRpb24gdXNlZC4NCiBCeSBkZWZhdWx0LCBwZXItZmxv dyBzY2hlZHVsaW5nIGlzIHVzZWQsIGVzcGVjaWFsbHkgZm9yIHRoZSB0cmFuc3BvcnQgcHJvdG9j b2xzIHRoYXQgYXJlIHNlbnNpdGl2ZSB0byByZW9yZGVyaW5nLCBzdWNoIGFzIFRDUC4gVGhlIHBh dGggc2VsZWN0aW9uIGRlY2lzaW9uIGlzIG1hZGUgb24gdGhlIGZpcnN0IGRhdGFncmFtIGFuZCBh bGwgc3Vic2VxdWVudCBkYXRhZ3JhbXMgb2YgdGhlIHNhbWUgZmxvdyB1c2UgdGhlIHNhbWUgcGF0 aC4gSWYgdGhlDQogcGF0aCBpcyBkZXRlY3RlZCBicm9rZW4gYmVmb3JlIHRoZSBmbG93IGlzIGNs b3NlZCwgYW5vdGhlciBwYXRoIHdpdGggdGhlIG1vc3Qgc2ltaWxhciBtZXRyaWMgaXMgdXNlZC4g UGVyLWRhdGFncmFtIHNjaGVkdWxpbmcgaXMgcmVjb21tZW5kZWQgaWYgdGhlIHRyYWZmaWMgaXMg aW5zZW5zaXRpdmUgdG8gcmVvcmRlcmluZyBzdWNoIGFzIG5vbi1yZWxpYWJsZSB0cmFuc21pc3Np b24gb2YgbWVkaWEgdHJhZmZpYywgb3Igd2hlbiBlcmFzdXJlIGNvZGluZw0KIGlzIGFwcGxpZWQu IEluIHN1Y2ggY2FzZSwgZWFjaCBkYXRhZ3JhbSBzZWxlY3RzIHRoZWlyIHBhdGhzIGluZGVwZW5k ZW50bHkuPGJyPg0KPGJyPg0Kcy9lYWNoIGRhdGFncmFtIHNlbGVjdHMgdGhlaXIgcGF0aHMvZWFj aCBkYXRhZ3JhbSBzZWxlY3RzIGl0cyBwYXRocy88YnI+DQo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEJ5IGRlZmF1bHQsIHRoZSB0cmFmZmljIGxvYWQgaXMgZXF1YWxseSBkaXN0cmlidXRl ZCBpbiBtdWx0aXBsZSBwYXRocy4gT3RoZXIgcGF0aCBzY2hlZHVsaW5nPGJyPg0KPGJyPg0KTWF5 YmU8YnI+DQpzL3RoZSB0cmFmZmljIGxvYWQgaXMgZXF1YWxseSBkaXN0cmlidXRlZC90aGUgdHJh ZmZpYyBsb2FkIHNob3VsZCBiZSBlcXVhbGx5IGRpc3RyaWJ1dGVkLzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7Jmd0OyZuYnNwOyBt ZWNoYW5pc21zIChlLmcuLCBhc3NpZ25pbmcgbW9yZSB0cmFmZmljIG92ZXIgYmV0dGVyIHBhdGhz KSBhcmUgYWxzbyBwb3NzaWJsZSBhbmQgd2lsbCBub3QgaW1wYWN0IHRoZSBpbnRlcm9wZXJhYmls aXR5IG9mIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IEFuZCB3ZSB3aWxsIGFsc28gcmVwaHJhc2UgdGhlIHRleHQgaW4gc2VjdGlvbiA0Ljxi cj4NCiZndDs8YnI+DQomZ3Q7IExldCB1cyBrbm93IGlmIGl04oCZcyBPSyBmb3IgeW91Ljxicj4N CiZndDs8YnI+DQomZ3Q7IGJlc3Q8YnI+DQomZ3Q7PGJyPg0KJmd0OyBKaWF6aTxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgT24gMjMgTWF5IDIwMTcsIGF0IDE0OjEwLCBNaXJqYSBL dWVobGV3aW5kIChJRVRGKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQi PmlldGZAa3VlaGxld2luZC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEhpIEppYXppLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgdW5mb3J0dW5hdGVs eSwgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBpcyBub3QgY29ycmVjdCwgYXMgYmFzaWNhbGx5IGFu eSB0cmFuc3BvcnQgY2FuIGJlIGVuY2Fwc3VsYXRlZCBvdmVyIFVEUDo8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyBQZXItRGF0YWdyYW0gc2NoZWR1bGluZyBpcyByZWNvbW1lbmRlZCBm b3IgdHJhbnNwb3J0IGxheWVyIHByb3RvY29scyB0aGF0IGhhdmUgbGVzcyBjb25zdHJhaW50IG9u IGRhdGFncmFtIGFycml2aW5nIG9yZGVyIHN1Y2ggYXMgVURQLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgSSB3b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgUGVyLURhdGFncmFtIHNjaGVkdWxpbmcgaXMgb25seSBy ZWNvbW1lbmRlZCBpZiBpdCBpcyBrbm93biB0aGF0IHRoZSB0cmFmZmljIGlzIG5vdCBzZW5zaXRp dmUgdG8gcmVvcmRlcmluZywgZS5nLiBmb3Igbm9uLXJlbGlhYmxlIHRyYW5zbWlzc2lvbiBvZiBt ZWRpYSB0cmFmZmljLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4gdGhpcyBjYXNlIEkg d291bGQgZnVydGhlciByZWNvbW1lbmQgdG8gYWRkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgTm90ZSB0aGF0IHRoZSB1c2Ugb2YgcGF0aHMg d2l0aCBoaWdobHkgZGlmZmVyZW50IGRlbGF5cyBjYW4gc3RpbGwgaGF2ZSBhIG5lZ2F0aXZlIGlt cGFjdCBvbiB0aGVzZSBraW5kIG9mIHRyYW5zbWlzc2lvbnMsIGFzIHBhY2tldHMgdGhhdCBhcnJp dmUgdG9vIGxhdGUgbWF5IGJlIGlnbm9yZWQgYW5kIHRoZXJlZm9yZSBoYXZlIGJlZW4gdHJhbnNt aXR0ZWQgdW5uZWNlc3NhcmlseS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZ1cnRoZXIg SSBhbHNvIGRvbuKAmXQgYWdyZWUgdG8gdGhpcyBzZW50ZW5jZTo8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBJbiBsb3NzeSBuZXR3b3JrcywgcGVyLWRhdGFncmFtIHNjaGVkdWxpbmcg aXMgYWxzbyByZWNvbW1lbmRlZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEV2ZW4gaW4g bG9zc3kgbmV0d29ya3MsIHBlci1kYXRhZ3JhbSBzY2hlZHVsaW5nIGlzIHN0aWxsIG5vdCByZWNv bW1lbmRlZCBmb3IgVENQIChpZiB0aGUgZGVsYXkgb2YgdGhlIGRpZmZlcmVudCBwYXRocyBhcmUg dG9vIGRpdmVyc2UpLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRmluYWxseSwgSSB3b3Vs ZCBmdXJ0aGVyIHJlY29tbWVuZCB5b3UgdG8gbm90IHNheSB0aGF0IHJvdW5kLXJvYmluIG5lZWRz IHRvIGJlIHVzZWQgaW4gc2VjdGlvbiA4LjQuIEkgYWxzbyBkb27igJl0IHRoaW5rIHlvdSBuZWVk IHRvIGhhdmUgdGhlIHR3byBidWxsZXQgcG9pbnRzIHRoYXQgZXhwbGFpbiB3aGF0IHBlci1kYXRh Z3JhbSBhbmQgcGVyLWZsb3cgbWVhbnMuIEl04oCZcyBlbm91Z2ggdG8gc2F5IHRoYXQgcGVyLWZs b3cgc2NoZWR1bGluZyBtZWFucw0KIHRoYXQgYSBkZWNpc2lvbiBpcyBtYWRlIG9uIHRoZSBmaXJz dCBwYWNrZXQgd2hpY2ggcGF0aCB0byB1c2UgYW5kIGFsbCBzdWJzZXF1ZW50IHBhY2tldHMgb2Yg dGhlIHNhbWUgZmxvdyAoZS5nLiBpZGVudGlmaWVkIGJ5IHRoZSA1LSBvciA2LXR1cGxlKSBuZWVk IHRvIHVzZSB0aGUgc2FtZSBwYXRoLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRnVydGhl ciBwbGVhc2UgYWxzbyBjaGVjayBzZWN0aW9uIDQgYXMgdGhpcyBhbHNvIG1ha2VzIGFzc3VtcHRp b25zIG9uIHRoZSBwYXRoIHNlbGVjdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRo YW5rcyw8YnI+DQomZ3Q7Jmd0OyBNaXJqYTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBbSAyMy4wNS4yMDE3IHVtIDEzOjQ5IHNjaHJp ZWIgSmlhemkgWWkgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGppYXppeWkuY29tIj5pZXRmQGpp YXppeWkuY29tPC9hPiZndDs6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IERl YXIgTWlyamEsPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRoYW5rIHZlcnkg bXVjaCBmb3IgeW91ciByZXBseS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg V2UgdW5kZXJzdGFuZCB5b3VyIGNvbmNlcm4gb24gdGhlIHBlcmZvcm1hbmNlLCBlc3BlY2lhbGx5 IHRoZSBpc3N1ZSBvZiBwYWNrZXQgcmVvcmRlcmluZyB3aGVuIHRoZSBtdWx0aXBhdGggcHJvdG9j b2wgaXMgYXBwbGllZCB0byB0cmFuc3BvcnQgcHJvdG9jb2wgbGlrZSBUQ1AuIFRoZXJlZm9yZSwg d2UgcHJvcG9zZSB0byBoYXZlIHNvbWUgZ3VpZGVsaW5lcyB0byBpbmRpY2F0ZSB3aGVuIHBlci1m bG93IHNjaGVkdWxpbmcgaXMgcmVjb21tZW5kZWQsDQogYW5kIHdoZW4gcGVyLXBhY2tldCBzY2hl ZHVsaW5nIGlzIHJlY29tbWVuZGVkLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyBNb3JlIHNwZWNpZmljYWxseSwgaW4gdGhlIGRyYWZ0LCB3ZSBwcm9wb3NlIHRoZSB0ZXh0Ojxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyA9PT09 PT09PT09PGJyPg0KJmd0OyZndDsmZ3Q7IEluIHNlY3Rpb24gMS4xLCBFeHBlcmltZW50cyB0byBi ZSBjb25kdWN0ZWQ6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDvigKIgRGlmZmVyZW50IHBhdGgtc2VsZWN0aW9uIHNjaGVkdWxlcnMuIERlcGVu ZGluZyBvbiB0aGUgYXBwbGljYXRpb24gdHlwZSBhbmQgdHJhbnNwb3J0IGxheWVyIHR5cGUgZWl0 aGVyIHBlci1mbG93IHNjaGVkdWxlciBvciBwZXItZGF0YWdyYW0gc2NoZWR1bGVyIGlzIGFwcGxp ZWQuIEJ5IGRlZmF1bHQsIHJvdW5kLXJvYmluIHNjaGVkdWxpbmcgaXMgdXNlZCB0byBzZWxlY3Qg YSBwYXRoIHRvIGJlIHVzZWQuIEluIHNvbWUgc2NlbmFyaW9zLA0KIHdlaWdodGVkIHNjaGVkdWxp bmcgY2FuIGJlIGNvbnNpZGVyZWQ6IGZvciBleGFtcGxlLCB0aGUgcGF0aHMgd2l0aCBsb3dlciBt ZXRyaWNzIChpLmUuLCBoaWdoZXIgcXVhbGl0eSkgY2FuIHRyYW5zZmVyIG1vcmUgZGF0YWdyYW1z IG9yIGZsb3dzIGNvbXBhcmVkIHRvIHBhdGhzIHdpdGggaGlnaGVyIG1ldHJpY3MuPGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEluIHNlY3Rpb24g OC40LCBEYXRhZ3JhbSBQcm9jZXNzaW5nIGF0IHRoZSBNUC1PTFNSdjIgT3JpZ2luYXRvcjxicj4N CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJZiBhIG1hdGNoaW5nIE11bHRpcGF0aCBS b3V0aW5nIFR1cGxlIGlzIG9idGFpbmVkLCB0aGUgUGF0aCBUdXBsZXMgb2YgdGhlIE11bHRpcGF0 aCBSb3V0aW5nIFR1cGxlIGFyZSBhcHBsaWVkIHRvIHRoZSBkYXRhZ3JhbXMgdXNpbmcgcm91bmQt cm9iaW4gc2NoZWR1bGluZy4gVGhlIHNjaGVkdWxpbmcgcG9saWN5IGNhbiBiZSBlaXRoZXIgcGVy LWZsb3cgb3IgcGVyLWRhdGFncmFtLCBkZXBlbmRpbmcgb24gdGhlIHRyYW5zcG9ydCBsYXllciBw cm90b2NvbA0KIGFuZCB0aGUgYXBwbGljYXRpb24gdXNlZDo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOy0gSW4gcGVyLWZsb3cgc2NoZWR1bGlu ZywgdGhlIGRhdGFncmFtcyBvZiB0aGUgc2FtZSBmbG93IGlzIHRyYW5zbWl0dGVkIHRocm91Z2gg dGhlIHNhbWUgcGF0aC4gRGlmZmVyZW50IGZsb3dzIGFyZSBhc3NpZ25lZCB0byBkaWZmZXJlbnQg cGF0aHMgYWNjb3JkaW5nIHRvIHJvdW5kLXJvYmluIHNjaGVkdWxpbmcuIEZvciBleGFtcGxlLCB0 aGVyZSBhcmUgMiBwYXRoIFR1cGxlcyAoUGF0aC0xLCBQYXRoLTIpIGZvciB0aGUgZGVzdGluYXRp b24NCiByb3V0ZXIgRC4gQSBzZXJpZXMgb2YgZmxvd3MgKEZsb3ctMSwgRmxvdy0yLCBGbG93LTMs IC4uLiBldGMuKSBhcmUgdG8gYmUgc2VudCB0byByb3V0ZXIgRC4gUGF0aC0xIGlzIHRoZW4gY2hv c2VuIGZvciBGbG93LTEsIFBhdGgtMiBmb3IgRmxvdy0yLCBQYXRoLTEgZm9yIEZsb3cgMywgZXRj Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 LSBJbiBwZXItZGF0YWdyYW0gc2NoZWR1bGluZywgZGlmZmVyZW50IGRhdGFncmFtcyBhcmUgdHJh bnNtaXR0ZWQgdGhyb3VnaCBkaWZmZXJlbnQgcGF0aHMgYWNjb3JkaW5nIHRvIHJvdW5kLXJvYmlu IHNjaGVkdWxpbmcuIEZvciBleGFtcGxlLCB0aGVyZSBhcmUgMiBwYXRoIFR1cGxlcyAoUGF0aC0x LCBQYXRoLTIpIGZvciB0aGUgZGVzdGluYXRpb24gcm91dGVyIEQuIEEgc2VyaWVzIG9mIGRhdGFn cmFtcyAoUGFja2V0LTEsIFBhY2tldC0yLA0KIFBhY2tldC0zLCAuLi4gZXRjLikgYXJlIHRvIGJl IHNlbnQgdG8gcm91dGVyIEQuIFBhdGgtMSBpcyB0aGVuIGNob3NlbiBmb3IgUGFja2V0LTEsIFBh dGgtMiBmb3IgUGFja2V0LTIsIFBhdGgtMSBmb3IgUGFja2V0IDMsIGV0Yy48YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgUGVyLWZsb3cgc2NoZWR1bGluZyBpcyByZWNvbW1lbmRl ZCBmb3IgdHJhbnNwb3J0IGxheWVyIHByb3RvY29scyB0aGF0IHJlcXVpcmUgc3RyaWN0IG9yZGVy aW5nIG9mIHRoZSBkYXRhZ3JhbXMgc3VjaCBhcyBUQ1AuIEJ5IGRlZmF1bHQsIHBlci1mbG93IHNj aGVkdWxpbmcgaXMgdXNlZC4gUGVyLURhdGFncmFtIHNjaGVkdWxpbmcgaXMgcmVjb21tZW5kZWQg Zm9yIHRyYW5zcG9ydCBsYXllciBwcm90b2NvbHMgdGhhdCBoYXZlIGxlc3MgY29uc3RyYWludA0K IG9uIGRhdGFncmFtIGFycml2aW5nIG9yZGVyIHN1Y2ggYXMgVURQLiBJbiBsb3NzeSBuZXR3b3Jr cywgcGVyLWRhdGFncmFtIHNjaGVkdWxpbmcgaXMgYWxzbyByZWNvbW1lbmRlZC48YnI+DQomZ3Q7 Jmd0OyZndDsgT3RoZXIgcGF0aCBzY2hlZHVsaW5nIG1lY2hhbmlzbXMgYXJlIGFsc28gcG9zc2li bGUgYW5kIHdpbGwgbm90IGltcGFjdCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBvZiBkaWZmZXJlbnQg aW1wbGVtZW50YXRpb25zLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyA9PT09 PT09PT09PTxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJZiBpdCBsb29rcyBn b29kIGZvciB5b3UsIHdlIHdpbGwgbWFrZSB0aGUgbW9kaWZpY2F0aW9uIGluIHRoZSBuZXh0IHJl dmlzaW9uIG9mIHRoZSBkcmFmdC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg cmVnYXJkczxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBKaWF6aTxicj4NCiZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgT24gMjIgTWF5IDIwMTcsIGF0IDEyOjE3LCBNaXJqYSBLdWVobGV3aW5kIChJ RVRGKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQiPmlldGZAa3VlaGxl d2luZC5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBIaSBKaWF6aSw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyBzb3JyeSBmb3IgbXkgdmVyeSBsYXRlIHJlcGx5LiBQbGVhc2Ugc2VlIGJlbG93Ljxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBbSAxMC4wNS4y MDE3IHVtIDAwOjUxIHNjaHJpZWIgSmlhemkgWWkgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGpp YXppeWkuY29tIj5pZXRmQGppYXppeWkuY29tPC9hPiZndDs6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBEZWFyIE1pcmphLDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIHZlcnkgbXVjaCBm b3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVhc2UgZmluZCB0aGUgcmVwbHkgaW5saW5l Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRElTQ1VTUzo8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZm9sbG93aW5n IHRleHQgaW4gc2VjdGlvbiA0IHNlZW1zIHRvIGluZGljYXRlIHRoYXQgc2NoZWR1bGluZyBpcyBk b25lPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9uIGEgcGVyLXBhY2tldCBiYXNpczo8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7V2hlbiB0aGVyZSBpcyBhPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRhdGFncmFtIHRvIGJlIHNlbnQgdG8gYSBkZXN0aW5h dGlvbiwgdGhlIHNvdXJjZSByb3V0ZXIgYWNxdWlyZXMgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBwYXRoIGZyb20gdGhlIE11bHRpLXBhdGggUm91dGluZyBTZXQgKE1BWSBiZSBSb3Vu ZC1Sb2Jpbiwgb3Igb3RoZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2NoZWR1bGlu ZyBhbGdvcml0aG1zKS4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBz ZWVtcyBub3QgYXBwcm9wcmlhdGUgYXMgZS5nLiBUQ1AgcGFja2V0cyByb3V0ZWQgb24gbGlua3Mg d2l0aDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsYXJnZWx5IGRpZmZlcmVudCBkZWxh eXMgbWF5IHN1ZmZlciBwZXJmb3JtYW5jZS4gRUNNUCB1c3VhbGx5IGhhc2hlcyB0aGU8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgNS10dXBsZSBvciA2LXR1cGxlIChpbmNsLiBEaWZmU2Vy diBDb2RlcG9pbnQpIHRvIHNldHVwIHN0YXRlIGFuZCByb3V0ZXM8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgYWxsIHBhY2tldHMgYmVsb25naW5nIHRvIHRoZSBzYW1lIGZsb3cgb24gdGhl IHNhbWUgcm91dGUuIEkgcmVjb21tZW5kIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFwcGx5IHRoZSBzYW1lIGhlcmUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFsc28gcmVsYXRlZCBpcyB0aGlzIHRleHQgaW4gc2Vj dGlvbiA4LjQgdGhhdCBzaG91bGQgZXhwbGFpbiBSb3VuZC1Sb2Jpbjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBvbiBhIHBlciBmbG93IGJhc2lzIGluc3RlYWQuIEZ1cnRoZXIgdGhpcyBz aG91bGQgb25seSBiZSBhbiBleGFtcGxlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNj aGVkdWxpbmcgYWxvZ2lydGhtIHdoaWxlIHRleHQgYmVsb25nIHNlZW1zIHRvIGFzc3VtZSB0aGF0 IFJvdW5kLVJvYmluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIGFsd2F5cyB1c2Vk Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtJZiBhIG1hdGNoaW5nIE11bHRp LXBhdGggUm91dGluZyBUdXBsZSBpcyBvYnRhaW5lZCwgdGhlIFBhdGggVHVwbGVzPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9mIHRoZSBNdWx0aS1wYXRoIFJvdXRpbmcgVHVwbGUgYXJl IGFwcGxpZWQgdG8gdGhlIGRhdGFncmFtcyB1c2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBSb3VuZC1yb2JpbiBzY2hlZHVsaW5nLiZuYnNwOyBGb3IgZXhhbXBsZSwgdGhlcmUgYXJl IDIgcGF0aCBUdXBsZXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKFBhdGgtMSwgUGF0 aC0yKSBmb3IgZGVzdGluYXRpb24gcm91dGVyIEQuIEEgc2VyaWVzIG9mIGRhdGFncmFtczxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoUGFja2V0LTEsIFBhY2tldC0yLCBQYWNrZXQtMywg Li4uIGV0Yy4pIGFyZSB0byBiZSBzZW50IHJvdXRlciBELjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBQYXRoLTEgaXMgdGhlbiBjaG9zZW4gZm9yIFBhY2tldC0xLCBQYXRoLTIgZm9yIFBh Y2tldC0yLCBQYXRoLTEgZm9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhY2tldCAz LCBldGMuJm5ic3A7IE90aGVyIHBhdGggc2NoZWR1bGluZyBtZWNoYW5pc21zIGFyZSBhbHNvIHBv c3NpYmxlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCB3aWxsIG5vdCBpbXBhY3Qg dGhlIGludGVyb3BlcmFiaWxpdHkgb2YgZGlmZmVyZW50PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGltcGxlbWVudGF0aW9ucy7igJ08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEluIGZhY3QsIHRoZSBwZXItcGFja2V0IHNjaGVkdWxpbmcg aXMgYW4gaW50ZW50aW9uYWwgY2hvaWNlIGJlY2F1c2U6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAxLiBUaGUgYWltZWQgc2NlbmFyaW8gaXMgbW9i aWxlIGFkIGhvYyBuZXR3b3Jrcywgd2hpY2ggaGF2ZSBoaWdoIHBhY2tldCBsb3NzIGJ5IG5hdHVy ZS4gT25lIG9mIHRoZSBtb3N0IGltcG9ydGFudCByZWFzb25zIGlzIHJvdXRlIGZhaWx1cmUgZHVl IHRvIG1vYmlsaXR5IOKAlCBpbiBzdWNoIGNhc2UsIGlmIGEgcGVyLWZsb3cgc2NoZWR1bGluZyBp cyBhcHBsaWVkLCB0aGUgd2hvbGUgZmxvdyB3aWxsIGxvc3QuIE9uIHRoZSBvdGhlciBoYW5kLA0K IGlmIHdlIHNlbmQgdGhlIHBhY2tldHMgaW4gZGlzam9pbnQgcGF0aHMgKG5vdCBuZWNlc3Nhcmls eSBlcXVhbCBjb3N0KSwgd2UgY2FuIHN0aWxsIG1ha2UgdXNlIHBhcnRpYWwgaW5mb3JtYXRpb24g b2YgdGhlIGZsb3csIG9yIGV2ZW4gcmVjb25zdHJ1Y3QgdGhlIGZsb3cgd2l0aCBlcmFzdXJlIGNv ZGluZy4gVGhpcyBpcyBlc3BlY2lhbGx5IGludGVyZXN0aW5nIGZvciB2aWRlby9hdWRpbyBzdHJl YW1pbmcuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBp cyBvbmx5IHRydWUgZm9yIHVucmVsaWFibGUgb3IgcGFydGlhbGx5IHJlbGlhYmxlIHRyYWZmaWMu IEkgc2VlIHlvdXIgdXNlIGNhc2UuIEhvd2V2ZXIsIHdpbGwgaWYgeW91IGhhdmUgVENQIHRyYWZm aWMsIHlvdSBjYW4gcHJvYmFibHkgYXNzdW1lIHRoYXQgdGhlIHRyYWZmaWMgaXMgcmVsaWFibGUg YW5kIHNob3VsZCBub3Qgcm91dGUgb24gYSBwZXItcGFja2V0IGJhc2lzLiBUaGlzIGNhc2UgaXMg bm90IGNvdmVyZWQgaW4geW91cg0KIGRyYWZ0LiBBbHNvIGZvciBvdGhlciBub24tVENQIHlvdSBv ZnRlbiBtaWdodCBub3Qga25vdyBtdWNoIGFib3V0IHRoZSB0cmFmZmljIGNoYXJhY3RlcmlzdGlj cyBhbmQgdGhlcmVmb3JlIGNhbm5vdCBrbm93IGlmIHBlci1wYWNrZXQgc2NoZWR1bGluZyBpcyBn b29kIG9yIGJhZC4gVGhlcmVmb3JlIGRlZmF1bHQgc2hvdWxkIGJlIHBlci1mbG93Ljxicj4NCiZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDIuIEluIHN1Y2gga2luZCBvZiBsb3NzeSBuZXR3b3JrcywgdGhlIHRyYWRpdGlv bmFsIFRDUCBwZXJmb3JtcyB2ZXJ5IHBvb3IgWzFdLiBTbyBhcyBmYXIgYXMgSSBrbm93LCBUQ1Ag aXMgbm90IHZlcnkgcG9wdWxhciBpbiBhZCBob2MgbmV0d29ya3MuIE9uIHRoZSBvdGhlciBoYW5k LCBiYXNlZCBvbiBvdXIgc3R1ZHksIHRoZSBtdWx0aS1wYXRoIHJvdXRpbmcgY2FuIGFjdHVhbGx5 IHJlZHVjZSB0aGUgb3ZlcmFsbCBqaXR0ZXIgWzJdLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IEkgZGlkbuKAmXQgaGF2ZSB0aW1lIHRvIHJlYWQgdGhlIHdob2xl IHBhcGVyIGJ1dCBvbiBhIGJyaWVmIGxvb2ssIGl0IGxvb2tzIGxpa2UgeW91IHRha2UgdGhlIGRl bGF5IGludG8gYWNjb3VudCBmb3IgVENQIHRyYWZmaWMuIFdoaWNoIGlzIHdoYXQgSSBzYWlkIGFi b3ZlOiBlaXRoZXIgeW91IGhhdmUgdHdvIGxpbmtzIHdoaWNoIGhhdmUgbW9yZSBvciBsZXNzIHRo ZSBzYW1lIGRlbGF5IG9yIHJlLW9yZGVyaW5nIHdpbGwgYmUgd3JvbmdseSBpbnRlcnByZXRlZA0K IGFzIGNvbmdlc3Rpb24uIFRoZSBvdGhlciBwcm9ibGVtIGlzIFRDUCByZWR1Y2VzIGl0cyBzZW5k aW5nIHJhdGUgZHVlIHRvIGxvc3MuIFNvIGlmIGJvdGggbGlua3MgYXJlIGNvbmdlc3RlZCBhbmQg bG9zc2VzIG9jY3VycmVkIChpbiBhIG5vbi1zeW5jaHJvbml6ZWQgd2F5KSwgVENQIHdpbGwgcmVh Y3QgdG8gYm90aCBzaWduYWxzIGFuZCByZWR1Y2UgaXRzIHNlbmRpbmcgcmF0ZSBtb3JlIHRoYW4g bmVjZXNzYXJ5LiBUaGF0J3Mgd2h5IEkgd291bGQNCiByZWNvbW1lbmQgdG8gc2NoZWR1bGUgVENQ IGFzIHdlbGwgYXMgb3RoZXIgcmVsaWFibGUgYW5kIGNvbmdlc3Rpb24tY29udHJvbGxlZCB0cmFm ZmljIG9uIGEgcGVyLWZsb3cgYmFzZS4gRnVydGhlciBmb3IgVURQIHRyYWZmaWMgdGhlcmUgaXMg bm8gZ29vZCB3YXkgdG8gYWN0dWFsbHkga25vdyBpZiB0aGUgdHJhZmZpYyBpcyByZWxpYWJseSB0 cmFuc21pdHRlZCBhbmQgY29uZ2VzdGlvbiBjb250cm9sLCBzbyBpdOKAmXMgaGFyZCB0byBtYWtl IHN1Y2gNCiBhIGRlY2lzaW9uIGluIHRoZSBuZXR3b3JrIGluIGEgZ2VuZXJhbCBjYXNlLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFdlIHVuZGVyc3RhbmQgeW91ciBjb25jZXJuIG9uIHRoaXMgaXNzdWUgKGFu ZCB5b3UgY2FuIGltYWdpbmUgdGhhdCB5b3UgYXJlIG5vdCB0aGUgZmlyc3Qgb25lIHdobyByYWlz ZXMgdGhpcyA7KS4gSXQgaXMgYWxzbyBzb21ldGhpbmcgdGhhdCB3ZSB3YW50IHRvIGhhdmUgZnVy dGhlciBleHBlcmllbmNlIGZyb20gdGhpcyAqZXhwZXJpbWVudGFsKiBkcmFmdCwgYXMgd2Ugc3Rh dGVkIGluIHRoZSDigJxleHBlcmltZW50cyB0byBiZSBjb25kdWN0ZWTigJ0NCiBzZWN0aW9uOjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A74oCiIERpZmZlcmVudCBwYXRoLXNlbGVjdGlvbiBzY2hlZHVsZXJzLiBCeSBkZWZhdWx0 LCByb3VuZC1yb2JpbiBzY2hlZHVsaW5nIGlzIHVzZWQgdG8gc2VsZWN0IGEgcGF0aCB0byBiZSB1 c2VkIGZvciBkYXRhZ3JhbXMuIEluIHNvbWUgc2NlbmFyaW9zLCB3ZWlnaHRlZCBzY2hlZHVsaW5n IGNhbiBiZSBjb25zaWRlcmVkOiBmb3IgZXhhbXBsZSwgdGhlIHBhdGhzIHdpdGggbG93ZXIgbWV0 cmljcyAoaS5lLiwgaGlnaGVyIHF1YWxpdHkpIGNhbg0KIHRyYW5zZmVyIG1vcmUgZGF0YWdyYW1z IGNvbXBhcmVkIHRvIHBhdGhzIHdpdGggaGlnaGVyIG1ldHJpY3MuPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgJm5ic3A74oCiIFRoZSBpbXBhY3RzIG9mIHRoZSBkZWxheSB2YXJpYXRp b24gZHVlIHRvIG11bHRpcGF0aCByb3V0aW5nLiBbUkZDMjk5MV0gYnJpbmdzIG91dCBzb21lIGNv bmNlcm5zIG9mIG11bHRpcGF0aCByb3V0aW5nLCBlc3BlY2lhbGx5IHZhcmlhYmxlIGxhdGVuY2ll cy4gQWx0aG91Z2ggY3VycmVudCBleHBlcmltZW50IHJlc3VsdHMgc2hvdyB0aGF0IG11bHRpcGF0 aCByb3V0aW5nIGNhbiByZWR1Y2UgdGhlIGppdHRlciBpbiBkeW5hbWljIHNjZW5hcmlvcywNCiBz b21lIHRyYW5zcG9ydCBwcm90b2NvbHMgb3IgYXBwbGljYXRpb25zIG1heSBiZSBzZW5zaXRpdmUg dG8gdGhlIGRhdGFncmFtIHJlLW9yZGVyaW5nLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7ICZuYnNwO+KAoiBUaGUgZGlzam9pbnQgbXVsdGlwYXRoIHByb3RvY29sIGhhcyBpbnRlcmVz dGluZyBhcHBsaWNhdGlvbiB3aXRoIGVyYXN1cmUgY29kaW5nLCBlc3BlY2lhbGx5IGZvciBzZXJ2 aWNlcyBsaWtlIHZpZGVvL2F1ZGlvIHN0cmVhbWluZyBbV1BNQzExXS4gVGhlIGNvbWJpbmF0aW9u IG9mIGVyYXN1cmUgY29kaW5nIG1lY2hhbmlzbXMgYW5kIHRoaXMgZXh0ZW5zaW9uIGlzIHRodXMg ZW5jb3VyYWdlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBU aGF04oCZcyBmaW5lIGJ1dCB0aGVuIHlvdSBjYW5ub3QgYXNzdW1lIGluIHRoZSByZXN0IG9mIHRo ZSBkb2N1bWVudCB0aGF0IHBlci1wYWNrZXQgc2NoZWR1bGluZyBpcyB1c2VkLjxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGFyZSB0d28gb3B0aW9ucyB0 byBoYW5kbGUgdGhpczogZWl0aGVyIHlvdSByZW1vdmUgdGhlIHRleHQgdGhhdCBpcyBjaXRlZCBh Ym92ZSBhbmQgZG8gbm90IHRhbGsgYWJvdXQgc2NoZWR1bGluZyBhdCBhbGwgb3RoZXIgdGhhbiBp biB0aGUgZXhwZXJpbWVudGF0aW9uIHBhcnQsIG9yIHlvdSBleHBsYWluIGNhcmVmdWxseSB3aGVu IHBvdGVudGlhbGx5IHBlci1wYWNrZXQgc2NoZWR1bGluZyBjb3VsZCBiZSB1c2VkIGFuZCBtYWtl DQogY2xlYXIgdGhhdCBieSBkZWZhdWx0IGFuZCBlc3BlY2lhbGx5IGZvciBUQ1AgcGVyLWZsb3cg c2NoZWR1bGluZyBzaG91bGQgYmUgdXNlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbMV0gUGVyZm9ybWFuY2UgRXZhbHVh dGlvbiBvZiBUQ1Agb3ZlciBNb2JpbGUgQWQtaG9jIE5ldHdvcmtzIDxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fYXJ4aXYub3JnX3Bk Zl8xMDAyLjIxODkucGRmJmFtcDtkPUR3TUZhUSZhbXA7Yz1MbFV2aWR2bGhTdEdVU3hRbDBnaU9B JmFtcDtyPVF6Z0NLbEstZVVzYkxXNXI4S1pBTDlMX3lxTk9OMWRiS3RNYS1XYnhuYTgmYW1wO209 ZGplN21RWUlpRkRqZ2JKSzhtVnB3aUw5NnpnMm05OUxxczNtVlFHcEVmayZhbXA7cz1rVnJrNTlm S2tjTDFWN1FyN0w5Z2xuR1E5eUNod1dTWGhqMGFDTkZuMmRvJmFtcDtlPSIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly9hcnhpdi5vcmcvcGRmLzEwMDIuMjE4OS5wZGY8L2E+PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgWzJdIE11bHRpcGF0aCBvcHRpbWl6ZWQgbGluayBzdGF0ZSByb3V0aW5n IGZvciBtb2JpbGUgYWQgaG9jIG5ldHdvcmtzJnF1b3Q7LCBJbiBFbHNldmllciBBZCBIb2MgSm91 cm5hbCwgdm9sLjksIG4uIDEsIDI4LTQ3LCBKYW51YXJ5LCAyMDExLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFJlbGF0ZWQgaXMgdGhpcyB0ZXh0IGluIHNlY3Rpb24gOC40Ljo8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7SWYgZGF0YWdyYW1zIHdpdGhvdXQgc291cmNl IHJvdXRpbmcgaGVhZGVyIG5lZWQgdG8gYmUgZm9yd2FyZGVkIHVzaW5nPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IG11bHRpcGxlIHBhdGhzIChmb3IgZXhhbXBsZSwgYmFzZWQgb24gdGhl IGluZm9ybWF0aW9uIG9mIERpZmZTZXJ2PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENv ZGUgUG9pbnQgW1JGQzI0NzRdKSZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBS RkMyNDc0IGRvZXMgbm90IHNwZWNpZnkgYW55IGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50cyBvbiBt dWx0aXBhdGggdXNlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFuZCBhcyBzdWNoIHRo ZSBEaWZmU2VydmUgZmllbGQgc2hvdWxkIG5vdCBiZSB1c2VkIHRvIGRldGVybWluZSBpZiB0aGU8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZmxvdyBjYW4gYmUgcm91dGVkIG9uIG11bHRp cGxlIHBhdGhzLiBUaGUgYWJpbGl0eSB0byBwcm9maXQgZnJvbTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBtdWx0aXBhdGggcm91dGluZyBkZXBlbmRzIG5vdCBvbmx5IG9uIHRoZSBhcHBs aWNhdGlvbiBhbmQgcHJvdG9jb2xzIHVzZWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg YnV0IGFsc28gb24gdGhlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbXVsdGlwYXRoIGxpbmsocyk7 IHNvIGl0J3MgaGFyZCB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWtlIGFueSBp bXBsaWNpdCBhc3N1bXB0aW9ucyBoZXJlLiBIb3dldmVyLCBpZiByb3V0aW5nIHdvdWxkIG9ubHkg YmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjb21tZW5kZWQgb24gYSBwZXItZmxv dyBiYXNpcyB0aGlzIHByb2JsZW0gZG9lcyBub3Qgb2NjdXIgYW5kIHRoZTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBicmFja2V0cyBhYm92ZSBjb3VsZCBiZSByZW1vdmUuIEZ1cnRoZXIs IGlmIHJvdXRlZCBvbiBhIHBlciBmbG93IGJhc2lzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHdvdWxkIGJlIGRvbmUsIERpZmZTZXJ2IGNvdWxkIGFjdHVhbGx5IGJlIHVzZWQgdG8gZGVj aWRlIHdoaWNoIHBhdGggdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdXNlLCBpZiBl LmcuIG9uZSBwYXRoIGhhcyBhIGxvd2VyIGRlbGF5LCBidXQgdGhhdCBzZWVtIHRvIG5lZWQgZnVy dGhlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkaXNjdXNzaW9uIGFzIHdlbGwuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBcyB3ZSBt ZW50aW9uZWQgYmVmb3JlLCB0aGUgbXVsdGlwYXRoIHJvdXRpbmcgaGFzIHNwZWNpYWwgaW50ZXJl c3RzIGluIGF1ZGlvL3ZpZGVvIHN0cmVhbWluZyBhcHBsaWNhdGlvbnMuIEZvciBhcHBsaWNhdGlv bnMgdGhhdCByZXF1aXJlcyBzdHJpY3Qgb3JkZXJpbmcsIHNpbmdsZSBwYXRoIGNhbiBiZSB1c2Vk LiBGb3Igc3RyZWFtaW5nIGFuZCB0aW1lLWNyaXRpY2FsIGFwcGxpY2F0aW9ucywgdGhlIG11bHRp LXBhdGggYXBwbGljYXRpb24NCiBtaWdodCBiZSBtb3JlIGludGVyZXN0aW5nLCB3aGljaCBjYW4g YmUgaWRlbnRpZmllZCBieSB0aGUgRGlmZlNlcnZlIGluZm9ybWF0aW9uLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFdoaWNoIERpZmZTZXJ2IGNvZGVwb2ludHMg YXJlIHlvdSB0YWtpbmcgYWJvdXQ/IFNvbWUgb2YgdGhlIGNvZGUgcG9pbnRzIHJlcXVpcmUgbG93 IGRlbGF5IGJ1dCB0aGV5IGVpdGhlciBzYXkgbm90aGluZyBhYm91dCByZW9yZGVyaW5nIG9yIHJl cXVpcmUgYSBib3VuZGVkIGppdHRlciBhcyB3ZWxsIHdoaWNoIG1lYW4gZm9yd2FyZGluZyBvbiBh IHBlci1wYWNrZXQgYmFzaXMgb3ZlciB0d28gbGlua3Mgd2hpY2ggaGlnaGx5IGRpZmZlcmVudA0K IGRlbGF5cyBzaG91bGQgbm90IGJlIGRvbmUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgTWlyamE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ09N TUVOVDo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNaW5v ciBjb21tZW50cy9xdWVzdGlvbnM6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEpIHNlY3Rpb24gOC40OiB0aGlzIHNlbnRlbmNlIGlz IG5vdCBjbGVhcjo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7SXQgaXMgUkVD T01NRU5ERUQgdG8gdXNlIE1UVSBzaXplcyBjb25zaWRlcmluZyB0aGUgc291cmNlIHJvdXRpbmc8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaGVhZGVyIHRvIGF2b2lkIGZyYWdtZW50YXRp b24uJnF1b3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1BWUJFPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90O0l0IGlzIE5PVCBSRUNPTU1FTkRFRCB0byBmcmFnbWVu dCB0aGUgSVAgcGFja2V0IGlmIHRoZSBwYWNrZXQgd2l0aCB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgc291cmNlIHJvdXRpbmcgaGVhZGVyIHdvdWxkJm5ic3A7IGV4Y2VlZCB0aGUg bWluaW11bSBNVFUgYWxvbmcgdGhlIHBhdGguIEluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHRoaXMgY2FzZSBzb3VyY2Ugcm91dGluZyBhbmQgdGhlcmVmb3JlIHRoZSBhZGRpdGlvbmFs IHBhdGggY2FsY3VsYXRlZCBieTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNUC1PTFNS djIgU0hPVUxEIE5PVCBiZSB1c2VkLuKAnTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRml4ZWQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg Mikgc2VjdGlvbiA5Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtGb3IgSVB2 NiBuZXR3b3JrcywgaXQgTVVTVDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDtiZSBzZXQgdG8gMCwgaS5lLiwgbm8gY29uc3RyYWludCBvbiBtYXhpbXVtIG51bWJlciBv ZiBob3BzLiZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXaHkgaXMgdGhhdD88 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJlY2F1 c2UgdGhlIGN1cnJlbnQgUkZDNjU1NCBzdXBwb3J0cyBvbmx5IElQdjYgc3RyaWN0IHNvdXJjZSBy b3V0aW5nLCB3ZSB0aHVzIG5lZWQgdG8ga2VlcCBhbGwgdGhlIHBhdGggaW5mb3JtYXRpb24gaW4g dGhlIHNvdXJjZSByb3V0aW5nIGhlYWRlciwgaW4gd2hpY2ggY2FzZSB3ZSBkb27igJl0IGtub3cg dGhlIG51bWJlciBvZiBob3BzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgT24gdGhlIG90aGVyIGhhbmQsIHdlIG5vdGljZWQgdGhhdCB0aGUgSVB2 NiBzZWdtZW50IHJvdXRpbmcgaGVhZGVyIGlzIGJlaW5nIGRpc2N1c3NlZCBhdCA2bWFuLCB3ZSB0 aHVzIGhhdmUgdGhlIGZvbGxvd2luZyB0ZXh0IGluIHRoZSDigJxFeHBlcmltZW50cyB0byBiZSBj b25kdWN0ZWTigJ0gc2VjdGlvbjo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwO+KAoiBVc2Ugb2YgSVB2NiBsb29zZSBzb3VyY2Ug cm91dGluZy4gSW4gdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiwgb25seSBzdHJpY3Qgc291cmNl IHJvdXRpbmcgaXMgdXNlZCBmb3IgSVB2NiBiYXNlZCBvbiBbUkZDNjU1NF0uIEluIFtJ4oCRRC5p ZXRm4oCRNm1hbuKAkXNlZ21lbnTigJFyb3V0aW5n4oCRaGVhZGVyXSwgdGhlIHVzZSBvZiBsb29z ZSBzb3VyY2Ugcm91dGluZyBpcyBhbHNvIHByb3Bvc2VkIGluIElQdjYuIEluIHNjZW5hcmlvcyB3 aGVyZQ0KIHRoZSBsZW5ndGggb2YgdGhlIHNvdXJjZSByb3V0aW5nIGhlYWRlciBpcyBjcml0aWNh bCwgdGhlIGxvb3NlIHNvdXJjZSByb3V0aW5nIGNhbiBiZSBjb25zaWRlcmVkLjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDMpIE5vdCBzdXJlIHdoeSBzZWN0aW9uIDEyLjEuIGlzIHRoZXJl PyBDYW4gdGhpcyBiZSByZW1vdmVkPzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgUmVtb3ZlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFnYWlucywgd2UgYXBwcmVjaWF0ZSB5b3VyIHZhbHVhYmxl IGNvbW1lbnRzIGFuZCBob3BlIHRoYXQgb3VyIHJlcGx5IGFkZHJlc3NlcyB5b3VyIGNvbmNlcm4u PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWdh cmRzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBK aWF6aTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0 QGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX21hbmV0JmFtcDtkPUR3TUZhUSZhbXA7Yz1MbFV2aWR2bGhT dEdVU3hRbDBnaU9BJmFtcDtyPVF6Z0NLbEstZVVzYkxXNXI4S1pBTDlMX3lxTk9OMWRiS3RNYS1X YnhuYTgmYW1wO209ZGplN21RWUlpRkRqZ2JKSzhtVnB3aUw5NnpnMm05OUxxczNtVlFHcEVmayZh bXA7cz1KaGQ5cFYwQ3dfd1hLYm5sRnN0VlpJQ0t2bVRIel9GejVHMUF5all2a3NJJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t YW5ldDwvYT48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRA aWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fbWFuZXQmYW1wO2Q9RHdNRmFRJmFtcDtjPUxsVXZpZHZsaFN0R1VTeFFsMGdp T0EmYW1wO3I9UXpnQ0tsSy1lVXNiTFc1cjhLWkFMOUxfeXFOT04xZGJLdE1hLVdieG5hOCZhbXA7 bT1kamU3bVFZSWlGRGpnYkpLOG1WcHdpTDk2emcybTk5THFzM21WUUdwRWZrJmFtcDtzPUpoZDlw VjBDd193WEtibmxGc3RWWklDS3ZtVEh6X0Z6NUcxQXlqWXZrc0kmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KCjxIUj5UaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgY29udGFpbnM8QlI+CmluZm9ybWF0aW9uIGZyb20gaURpcmVjdCwgd2hpY2gg bWF5IGJlIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5PEJSPgphbmQvb3IgY29uZmlkZW50aWFsLiBJ dCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWw8QlI+Cm9y IGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIG9y aWdpbmFsPEJSPgpyZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZl cmluZyB0aGUgZW1haWwgdG8gdGhlPEJSPgppbnRlbmRlZCByZWNpcGllbnQsIGJlIGFkdmlzZWQg dGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsPEJSPgppbiBlcnJvciwgYW5kIHRoYXQg YW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcsIG9yPEJSPgpjb3B5 aW5nIG9mIHRoaXMgZW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVk IHRoaXMgZW1haWw8QlI+CmluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBpbW1lZGlhdGVs eSBub3RpZnkgdGhlIHNlbmRlci48QlI+CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_b72836e7c79044189181bd5a2fa7995aVAUSDITCHM2idirectnet_-- From nobody Fri May 26 09:37:40 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D033D127909 for ; Fri, 26 May 2017 09:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1iqt1QQQpGC for ; Fri, 26 May 2017 09:37:34 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BD0129B16 for ; Fri, 26 May 2017 09:37:33 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id v27so12483328qtg.2 for ; Fri, 26 May 2017 09:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YyyY0P5FelRTmB/yOJ3TtclZBgK2NN845gr7qrT8RNo=; b=aI0y7seMI+omSPF2tntRJ265uS3191u9YVKk1VyttQmKjEIO5Sf/RpvAjolZdi8q5o uAR7lNm8WI23rzrl4NIJw/tvIX3vd+GB8NzY58ZTTrMj9Tsa4m44BZQJephjSPhwUbiF b6udiRkWYQ42pEO5bHblVUqhO+I5znme61/ZV6GxanObFSdKt8V5v0kYt/kcnZrRmuGT JfZh0oZedZ3Xo+Ee3S+Ygn6O5SDczB2wih5OC1esOW9TASJSR5/6W3xKuSR3oEAQNZ5e O/52gx/tYvyE0kvA3d5ZT5spm0ykvIKC9NvzEBG4iJT5Kd+ST78IKT0bMg6zyp97kGrS 9DHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YyyY0P5FelRTmB/yOJ3TtclZBgK2NN845gr7qrT8RNo=; b=PaDzF2d7WJF3mQLcENkPKCsfdGuuOop8wZNjfL7rCHRUu2+5VHtIY6jyPZp04zz5p3 WAfVLs5uQ+w8vM+/WT+dhLoxkdEyRt8n0KPffXxoHUbvJQxhyJ8NdbYPaeWcXRGmngnz FhRdvKt7tdHHtDdEoEmX8wQuJka1PD/UvkLcMcQ/QLTpMugjX/TyKJIjPNbOzS9Z8Ahk FT2XnlLqCer59jmKGb6t/8YF7lZM5WsFGxJ0oYq14g2UkzImRdEUNw4ifFnXOPAkSEn3 hhpi9kE7zCv2tI6F5qoB9GGjosWoVo6dIiAJeydknPQiAu/l1msiGO6urFw/5+iL7dgw lwFw== X-Gm-Message-State: AODbwcDDBuwuTlrf9+6MJNskvjBXKiztwmEf7gv8E+AlHTByy8vtrJUx cxdrHwYvsYJyA/FLy0uzUP4uNcR3PQ== X-Received: by 10.237.34.142 with SMTP id p14mr3433596qtc.90.1495816652401; Fri, 26 May 2017 09:37:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.52 with HTTP; Fri, 26 May 2017 09:37:31 -0700 (PDT) In-Reply-To: References: <149428609109.22424.5784376043805292120.idtracker@ietfa.amsl.com> <3A65E7B9-5614-422D-B9A7-191A43411D25@jiaziyi.com> <7A04E6A6-7D62-4FE3-BCC2-DFF615EADDD1@jiaziyi.com> <8D2233B8-FECE-462B-8D55-7C5CCCC6F9C3@kuehlewind.net> <751656CF-E1E2-4748-BB30-A203D893DE6F@kuehlewind.net> From: Abdussalam Baryun Date: Fri, 26 May 2017 18:37:31 +0200 Message-ID: To: "Ratliff, Stanley" Cc: "Mirja Kuehlewind (IETF)" , manet Content-Type: multipart/alternative; boundary="001a1137751e3730ea05506ff43c" Archived-At: Subject: Re: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-manet-olsrv2-multipath-12=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 16:37:40 -0000 --001a1137751e3730ea05506ff43c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did not reference 8.4, just reply to the discussing about TCP, so we don't do routing on TCP ports, yes we can have data plane using manet paths but not reliable, so the discussion about reliability was not related. I think the multipath work needs clear assignments for IPv4 and IPv6 not just following RPL 6554 . I should not think about what is implemented/used-RFC now, but we may think of what if all our RFCs become implemented over night, so it should be perfect or workable otherwise our review failed. My attention was that we have allocated issues and I am talking as if thy are implemented (MANET protocols usually are used, but no one will tell you he implemented it if he/she did, they just use it). AB On Fri, May 26, 2017 at 6:11 PM, Ratliff, Stanley wrote: > AB, > > > > The text you reference in Section 8.4 is talking about the data being > routed; not about the control plane (OLSR) traffic. For example, if regul= ar > browser traffic were to be carried by an OLSR network with the multipath > enhancement, said browser traffic (which is TCP-based) MUST be delivered = by > the network in-sequence. The restriction stated in Section 8.4 preserves > the ordering, since the traffic follows the same path. > > > > As to RFC5444 =E2=80=93 IIRC, the WG decision at the time was to allow fo= r both > operation using UDP as a transport between routers, as well as for Layer = 3 > communication (as OSPF does). The decision of whether to support UDP > communication or Layer 3 communication is implementation-dependent. AFAIK= , > there are no Layer 3 implementations presently, but if anyone on the list > knows of one, please correct me. However, that is the reason both a UDP > port number and an IP number were allocated. > > > > Regards, > > Stan > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Abdussalam > Baryun > *Sent:* Friday, May 26, 2017 11:52 AM > *To:* Mirja Kuehlewind (IETF) > *Cc:* manet ; The IESG ; > draft-ietf-manet-olsrv2-multipath@ietf.org > *Subject:* Re: [manet] Mirja K=C3=BChlewind's Discuss on > draft-ietf-manet-olsrv2-multipath-12: (with DISCUSS and COMMENT) > > > > Hi Mirja, and IESG, > > > > You first mentioned TCP or reliability in your first message and authors > replying too, but IMO, in MANET WG drafts under IETF we still have no > routing through TCP because our MANET-Packet as in RFC5444, is only havin= g > as mentioned in RFC5498 the IP number 138 and the UDP port number. So our > OLSRv2 routers don't do any TCP ports. Regarding reliability, I don't thi= nk > it is right to mention the reliability in MANET/this-draft, because it ma= y > need many other considerations. > > > > I think that we need to clarify in this draft the manet packet rfc5444, > and that it takes the manet messages including the multipaths. So in the > draft mentions datagram, but not manet packet which is 5444 packet, is ou= r > source routing at ip layer or transport layer do we need ip number or > transport port number. > > > > We need to add the below to section 12 as it was done in rfc7181 and 7722= : > > > > Expert Review: Evaluation Guidelines: > For the registry where an Expert Review is required, the designated > expert SHOULD take the same general recommendations into > consideration as are specified by [RFC5444], [RFC5498], [RFC7631] > and [RFC7722]. > > > > This draft is using the same header type of rfc6554 which I may disagree. > Furthermore, in RFC6554 routing has mentioned in its IANA section the > assigned ipv6 number is 3 for RPL source routing (this draft is not for > RPL), so for this multipath-protocol, we need to assign an IPv4 number fo= r > the manet-source-routing, and we should mention it in section 12 as usin= g > 138 for IPv6 for manet packets 5444. As we have done in MANET DSR source > routing RFC4728 assigned it for IPv4 number 48. > > > > In section 12 we need to update the table -1 to have a title similar to > 7722 which is: > > > > Type 7 Message TLV Type Extensions > > > > however, and that we add the references and type extensions of 0 and 1 > which were allocated already. Add references in table 1 as 7181 and 7722. > > > > take care, > > AB > > > > On Wed, May 24, 2017 at 1:22 PM, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > > Thanks! That=E2=80=99s much better! > > Two nits below. > > Mirja > > > > Am 24.05.2017 um 00:26 schrieb Jiazi Yi : > > > > Hi Mirja, > > > > Thanks very much for your input. Now we have the text for section 8.4: > > > >> If a matching Multipath Routing Tuple is obtained, the Path Tuples of > the Multipath Routing Tuple are applied to the datagrams using either > per-flow scheduling or per-datagram scheduling, depending on the transpor= t > layer protocol and the application used. By default, per-flow scheduling = is > used, especially for the transport protocols that are sensitive to > reordering, such as TCP. The path selection decision is made on the first > datagram and all subsequent datagrams of the same flow use the same path. > If the path is detected broken before the flow is closed, another path wi= th > the most similar metric is used. Per-datagram scheduling is recommended i= f > the traffic is insensitive to reordering such as non-reliable transmissio= n > of media traffic, or when erasure coding is applied. In such case, each > datagram selects their paths independently. > > s/each datagram selects their paths/each datagram selects its paths/ > > >> > >> By default, the traffic load is equally distributed in multiple paths. > Other path scheduling > > Maybe > s/the traffic load is equally distributed/the traffic load should be > equally distributed/ > > > >> mechanisms (e.g., assigning more traffic over better paths) are also > possible and will not impact the interoperability of different > implementations. > > > > > > And we will also rephrase the text in section 4. > > > > Let us know if it=E2=80=99s OK for you. > > > > best > > > > Jiazi > > > > > >> On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) > wrote: > >> > >> Hi Jiazi, > >> > >> unfortunately, the following sentence is not correct, as basically any > transport can be encapsulated over UDP: > >> > >>> Per-Datagram scheduling is recommended for transport layer protocols > that have less constraint on datagram arriving order such as UDP. > >> > >> I would propose the following sentence: > >> > >>> Per-Datagram scheduling is only recommended if it is known that the > traffic is not sensitive to reordering, e.g. for non-reliable transmissio= n > of media traffic. > >> > >> In this case I would further recommend to add the following sentence: > >> > >>> Note that the use of paths with highly different delays can still hav= e > a negative impact on these kind of transmissions, as packets that arrive > too late may be ignored and therefore have been transmitted unnecessarily= . > >> > >> Further I also don=E2=80=99t agree to this sentence: > >> > >>> In lossy networks, per-datagram scheduling is also recommended. > >> > >> Even in lossy networks, per-datagram scheduling is still not > recommended for TCP (if the delay of the different paths are too diverse)= . > >> > >> Finally, I would further recommend you to not say that round-robin > needs to be used in section 8.4. I also don=E2=80=99t think you need to h= ave the > two bullet points that explain what per-datagram and per-flow means. It= =E2=80=99s > enough to say that per-flow scheduling means that a decision is made on t= he > first packet which path to use and all subsequent packets of the same flo= w > (e.g. identified by the 5- or 6-tuple) need to use the same path. > >> > >> Further please also check section 4 as this also makes assumptions on > the path selection. > >> > >> Thanks, > >> Mirja > >> > >> > >> > >>> Am 23.05.2017 um 13:49 schrieb Jiazi Yi : > >>> > >>> Dear Mirja, > >>> > >>> Thank very much for your reply. > >>> > >>> We understand your concern on the performance, especially the issue o= f > packet reordering when the multipath protocol is applied to transport > protocol like TCP. Therefore, we propose to have some guidelines to > indicate when per-flow scheduling is recommended, and when per-packet > scheduling is recommended. > >>> > >>> More specifically, in the draft, we propose the text: > >>> > >>> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> In section 1.1, Experiments to be conducted: > >>> > >>> =E2=80=A2 Different path-selection schedulers. Depending on the > application type and transport layer type either per-flow scheduler or > per-datagram scheduler is applied. By default, round-robin scheduling is > used to select a path to be used. In some scenarios, weighted scheduling > can be considered: for example, the paths with lower metrics (i.e., highe= r > quality) can transfer more datagrams or flows compared to paths with high= er > metrics. > >>> > >>> > >>> In section 8.4, Datagram Processing at the MP-OLSRv2 Originator > >>> > >>> If a matching Multipath Routing Tuple is obtained, the Path Tuples of > the Multipath Routing Tuple are applied to the datagrams using round-robi= n > scheduling. The scheduling policy can be either per-flow or per-datagram, > depending on the transport layer protocol and the application used: > >>> > >>> - In per-flow scheduling, the datagrams of the same flow is > transmitted through the same path. Different flows are assigned to > different paths according to round-robin scheduling. For example, there a= re > 2 path Tuples (Path-1, Path-2) for the destination router D. A series of > flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be sent to router D. Path= -1 > is then chosen for Flow-1, Path-2 for Flow-2, Path-1 for Flow 3, etc. > >>> > >>> - In per-datagram scheduling, different datagrams are transmitted > through different paths according to round-robin scheduling. For example, > there are 2 path Tuples (Path-1, Path-2) for the destination router D. A > series of datagrams (Packet-1, Packet-2, Packet-3, ... etc.) are to be se= nt > to router D. Path-1 is then chosen for Packet-1, Path-2 for Packet-2, > Path-1 for Packet 3, etc. > >>> > >>> Per-flow scheduling is recommended for transport layer protocols that > require strict ordering of the datagrams such as TCP. By default, per-flo= w > scheduling is used. Per-Datagram scheduling is recommended for transport > layer protocols that have less constraint on datagram arriving order such > as UDP. In lossy networks, per-datagram scheduling is also recommended. > >>> Other path scheduling mechanisms are also possible and will not impac= t > the interoperability of different implementations. > >>> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> If it looks good for you, we will make the modification in the next > revision of the draft. > >>> > >>> regards > >>> > >>> Jiazi > >>> > >>> > >>> > >>>> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) < > ietf@kuehlewind.net> wrote: > >>>> > >>>> Hi Jiazi, > >>>> > >>>> sorry for my very late reply. Please see below. > >>>> > >>>>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi : > >>>>> > >>>>> Dear Mirja, > >>>>> > >>>>> Thanks very much for your review and comments. Please find the repl= y > inline: > >>>>> > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> DISCUSS: > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> > >>>>>> The following text in section 4 seems to indicate that scheduling > is done > >>>>>> on a per-packet basis: > >>>>>> "When there is a > >>>>>> datagram to be sent to a destination, the source router acquires a > >>>>>> path from the Multi-path Routing Set (MAY be Round-Robin, or other > >>>>>> scheduling algorithms)." > >>>>>> This seems not appropriate as e.g. TCP packets routed on links wit= h > >>>>>> largely different delays may suffer performance. ECMP usually > hashes the > >>>>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to setup state and > routes > >>>>>> all packets belonging to the same flow on the same route. I > recommend to > >>>>>> apply the same here. > >>>>>> > >>>>>> Also related is this text in section 8.4 that should explain > Round-Robin > >>>>>> on a per flow basis instead. Further this should only be an exampl= e > >>>>>> scheduling alogirthm while text belong seems to assume that > Round-Robin > >>>>>> is always used. > >>>>>> "If a matching Multi-path Routing Tuple is obtained, the Path Tupl= es > >>>>>> of the Multi-path Routing Tuple are applied to the datagrams using > >>>>>> Round-robin scheduling. For example, there are 2 path Tuples > >>>>>> (Path-1, Path-2) for destination router D. A series of datagrams > >>>>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent router D. > >>>>>> Path-1 is then chosen for Packet-1, Path-2 for Packet-2, Path-1 fo= r > >>>>>> Packet 3, etc. Other path scheduling mechanisms are also possible > >>>>>> and will not impact the interoperability of different > >>>>>> implementations.=E2=80=9D > >>>>> > >>>>> In fact, the per-packet scheduling is an intentional choice because= : > >>>>> > >>>>> 1. The aimed scenario is mobile ad hoc networks, which have high > packet loss by nature. One of the most important reasons is route failure > due to mobility =E2=80=94 in such case, if a per-flow scheduling is appli= ed, the > whole flow will lost. On the other hand, if we send the packets in disjoi= nt > paths (not necessarily equal cost), we can still make use partial > information of the flow, or even reconstruct the flow with erasure coding= . > This is especially interesting for video/audio streaming. > >>>> > >>>> This is only true for unreliable or partially reliable traffic. I se= e > your use case. However, will if you have TCP traffic, you can probably > assume that the traffic is reliable and should not route on a per-packet > basis. This case is not covered in your draft. Also for other non-TCP you > often might not know much about the traffic characteristics and therefore > cannot know if per-packet scheduling is good or bad. Therefore default > should be per-flow. > >>>> > >>>>> > >>>>> 2. In such kind of lossy networks, the traditional TCP performs ver= y > poor [1]. So as far as I know, TCP is not very popular in ad hoc networks= . > On the other hand, based on our study, the multi-path routing can actuall= y > reduce the overall jitter [2]. > >>>> > >>>> I didn=E2=80=99t have time to read the whole paper but on a brief lo= ok, it > looks like you take the delay into account for TCP traffic. Which is what= I > said above: either you have two links which have more or less the same > delay or re-ordering will be wrongly interpreted as congestion. The other > problem is TCP reduces its sending rate due to loss. So if both links are > congested and losses occurred (in a non-synchronized way), TCP will react > to both signals and reduce its sending rate more than necessary. That's w= hy > I would recommend to schedule TCP as well as other reliable and > congestion-controlled traffic on a per-flow base. Further for UDP traffic > there is no good way to actually know if the traffic is reliably > transmitted and congestion control, so it=E2=80=99s hard to make such a d= ecision in > the network in a general case. > >>>> > >>>>> > >>>>> We understand your concern on this issue (and you can imagine that > you are not the first one who raises this ;). It is also something that w= e > want to have further experience from this *experimental* draft, as we > stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section: > >>>>> > >>>>> =E2=80=A2 Different path-selection schedulers. By default, round-= robin > scheduling is used to select a path to be used for datagrams. In some > scenarios, weighted scheduling can be considered: for example, the paths > with lower metrics (i.e., higher quality) can transfer more datagrams > compared to paths with higher metrics. > >>>>> =E2=80=A2 The impacts of the delay variation due to multipath rou= ting. > [RFC2991] brings out some concerns of multipath routing, especially > variable latencies. Although current experiment results show that multipa= th > routing can reduce the jitter in dynamic scenarios, some transport > protocols or applications may be sensitive to the datagram re-ordering. > >>>>> =E2=80=A2 The disjoint multipath protocol has interesting applica= tion with > erasure coding, especially for services like video/audio streaming > [WPMC11]. The combination of erasure coding mechanisms and this extension > is thus encouraged. > >>>> > >>>> That=E2=80=99s fine but then you cannot assume in the rest of the do= cument > that per-packet scheduling is used. > >>>> > >>>> There are two options to handle this: either you remove the text tha= t > is cited above and do not talk about scheduling at all other than in the > experimentation part, or you explain carefully when potentially per-packe= t > scheduling could be used and make clear that by default and especially fo= r > TCP per-flow scheduling should be used. > >>>> > >>>> > >>>>> > >>>>> > >>>>> [1] Performance Evaluation of TCP over Mobile Ad-hoc Networks > https://arxiv.org/pdf/1002.2189.pdf > > >>>>> [2] Multipath optimized link state routing for mobile ad hoc > networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, January, 2011. > >>>>> > >>>>>> > >>>>>> Related is this text in section 8.4.: > >>>>>> "If datagrams without source routing header need to be forwarded > using > >>>>>> multiple paths (for example, based on the information of DiffServ > >>>>>> Code Point [RFC2474])" > >>>>>> RFC2474 does not specify any application requirements on multipath > use > >>>>>> and as such the DiffServe field should not be used to determine if > the > >>>>>> flow can be routed on multiple paths. The ability to profit from > >>>>>> multipath routing depends not only on the application and protocol= s > used > >>>>>> but also on the characteristics of the multipath link(s); so it's > hard to > >>>>>> make any implicit assumptions here. However, if routing would only > be > >>>>>> recommended on a per-flow basis this problem does not occur and th= e > >>>>>> brackets above could be remove. Further, if routed on a per flow > basis > >>>>>> would be done, DiffServ could actually be used to decide which pat= h > to > >>>>>> use, if e.g. one path has a lower delay, but that seem to need > further > >>>>>> discussion as well. > >>>>> > >>>>> As we mentioned before, the multipath routing has special interests > in audio/video streaming applications. For applications that requires > strict ordering, single path can be used. For streaming and time-critical > applications, the multi-path application might be more interesting, which > can be identified by the DiffServe information. > >>>> > >>>> Which DiffServ codepoints are you taking about? Some of the code > points require low delay but they either say nothing about reordering or > require a bounded jitter as well which mean forwarding on a per-packet > basis over two links which highly different delays should not be done. > >>>> > >>>> Mirja > >>>> > >>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> COMMENT: > >>>>>> ------------------------------------------------------------ > ---------- > >>>>>> > >>>>>> Minor comments/questions: > >>>>>> > >>>>>> 1) section 8.4: this sentence is not clear: > >>>>>> "It is RECOMMENDED to use MTU sizes considering the source routing > >>>>>> header to avoid fragmentation." > >>>>>> MAYBE > >>>>>> "It is NOT RECOMMENDED to fragment the IP packet if the packet wit= h > the > >>>>>> source routing header would exceed the minimum MTU along the path= . > In > >>>>>> this case source routing and therefore the additional path > calculated by > >>>>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D > >>>>> > >>>>> Fixed. > >>>>> > >>>>>> > >>>>>> 2) section 9: > >>>>>> "For IPv6 networks, it MUST > >>>>>> be set to 0, i.e., no constraint on maximum number of hops." > >>>>>> Why is that? > >>>>> > >>>>> Because the current RFC6554 supports only IPv6 strict source > routing, we thus need to keep all the path information in the source > routing header, in which case we don=E2=80=99t know the number of hops. > >>>>> > >>>>> On the other hand, we noticed that the IPv6 segment routing header > is being discussed at 6man, we thus have the following text in the > =E2=80=9CExperiments to be conducted=E2=80=9D section: > >>>>> > >>>>> =E2=80=A2 Use of IPv6 loose source routing. In the current specif= ication, > only strict source routing is used for IPv6 based on [RFC6554]. In > [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2=80=91routing=E2=80=91he= ader], the use of loose source routing > is also proposed in IPv6. In scenarios where the length of the source > routing header is critical, the loose source routing can be considered. > >>>>> > >>>>>> > >>>>>> 3) Not sure why section 12.1. is there? Can this be removed? > >>>>> > >>>>> Removed. > >>>>> > >>>>> Agains, we appreciate your valuable comments and hope that our repl= y > addresses your concern. > >>>>> > >>>>> regards > >>>>> > >>>>> Jiazi > >>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> manet mailing list > >>>>>> manet@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/manet > > >>> > >> > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > ------------------------------ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > --001a1137751e3730ea05506ff43c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0I did not reference 8.4, just reply to the disc= ussing about TCP, so we don't do routing on TCP ports, yes we can have = data plane using manet paths but not reliable, so the discussion about reli= ability was not related. I think the multipath work needs clear assignments= for IPv4 and IPv6 not just following RPL=C2=A06554=C2=A0.

I should not think about what is implemented/used-RFC now, but we = may think of what if all our RFCs become implemented over night, so it shou= ld be perfect or workable otherwise=C2=A0our review=C2=A0failed. My attenti= on was that we have allocated issues and I am talking as if thy are impleme= nted (MANET protocols usually are used,=C2=A0but no one will tell you he im= plemented it if he/she did, they just use it).

AB<= /div>

On Fri= , May 26, 2017 at 6:11 PM, Ratliff, Stanley <sratliff@idirect.net= > wrote:

AB,

=C2=A0

The text you reference in Sectio= n 8.4 is talking about the data being routed; not about the control plane (= OLSR) traffic. For example, if regular browser traffic were to be carried by an OLSR network with the multipath enhancement, said= browser traffic (which is TCP-based) MUST be delivered by the network in-s= equence. The restriction stated in Section 8.4 preserves the ordering, sinc= e the traffic follows the same path.

=C2=A0

As to RFC5444 =E2=80=93 IIRC, th= e WG decision at the time was to allow for both operation using UDP as a tr= ansport between routers, as well as for Layer 3 communication (as OSPF does). The decision of whether to support UDP communication or La= yer 3 communication is implementation-dependent. AFAIK, there are no Layer = 3 implementations presently, but if anyone on the list knows of one, please= correct me. However, that is the reason both a UDP port number and an IP number were allocated.

=C2=A0

Regards,

Stan

=C2=A0

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: Friday, May 26, 2017 11:52 AM
To: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
Cc: manet <ma= net@ietf.org>; The IESG <iesg@ietf.org>; draft-ietf-manet-olsrv2-multip= ath@ietf.org
Subject: Re: [manet] Mirja K=C3=BChlewind's Discuss on draft-iet= f-manet-olsrv2-multipath-12: (with DISCUSS and COMMENT)<= /span>

=C2=A0

Hi Mirja, and IESG,

=C2=A0

You first mentioned TCP or reliability=C2=A0in your = first message and authors replying too, but IMO, in MANET WG drafts under I= ETF=C2=A0we still have no routing through TCP because our MANET-Packet as i= n RFC5444, is only having as mentioned in RFC5498 the IP number 138 and the UDP port number. So our OLSRv2 routers don't= do=C2=A0any TCP ports. Regarding reliability, I don't think it is righ= t to mention the reliability in MANET/this-draft, because it may need many = other considerations.

=C2=A0

I think that we need to clarify in this =C2=A0draft = the manet packet rfc5444, and that it takes the manet messages including th= e multipaths. So in the draft mentions datagram, but not manet packet which= is 5444 packet, is our source routing at ip layer or transport layer do we need ip number or transport port numb= er.

=C2=A0

We need to add the below to section 12 as it was don= e in rfc7181 and 7722:

=C2=A0

Expert Review: Evaluation Guidelines:
=C2=A0=C2=A0 For the registry where an Expert Review is required, the desig= nated
=C2=A0=C2=A0 expert SHOULD take the same general recommendations into
=C2=A0=C2=A0 consideration as are specified by [RFC5444], [RFC5498], [RFC76= 31] and=C2=A0[RFC7722].

=C2=A0

This draft is using the same header type of rfc6554 = which I may disagree. Furthermore, in RFC6554 routing has mentioned in its = IANA section the assigned ipv6 number is 3 for RPL source routing (this dra= ft is not for RPL), so for this multipath-protocol, we need to assign an IPv4 number for the manet-source-routing,=C2=A0and = =C2=A0we should mention it in section 12 as using 138 for IPv6 for manet pa= ckets 5444. As we have done in MANET DSR source routing RFC4728 assigned it= for IPv4 number 48.=C2=A0

=C2=A0

In section 12 we need to update the table -1 to have= a title similar to 7722 which is:

=C2=A0

Type 7 Message TLV Type Extensions

=C2=A0

however, and that we add the references and type ext= ensions of 0 and 1 which were allocated already.=C2=A0Add references in tab= le 1 as 7181 and 7722.

=C2=A0

take care,

AB

=C2=A0

On Wed, May 24, 2017 at 1:22 PM, Mirja Kuehlewind (I= ETF) <ietf@kueh= lewind.net> wrote:

Thanks! That=E2=80=99s much better!

Two nits below.

Mirja


> Am 24.05.2017 um 00:26 schrieb Jiazi Yi <ietf@jiaziyi.com>:
>
> Hi Mirja,
>
> Thanks very much for your input. Now we have the text for section 8.4:=
>
>> If a matching Multipath Routing Tuple is obtained, the Path Tuples= of the Multipath Routing Tuple are applied to the datagrams using either p= er-flow scheduling or per-datagram scheduling, depending on the transport l= ayer protocol and the application used. By default, per-flow scheduling is used, especially for the transport prot= ocols that are sensitive to reordering, such as TCP. The path selection dec= ision is made on the first datagram and all subsequent datagrams of the sam= e flow use the same path. If the path is detected broken before the flow is closed, another path with the m= ost similar metric is used. Per-datagram scheduling is recommended if the t= raffic is insensitive to reordering such as non-reliable transmission of me= dia traffic, or when erasure coding is applied. In such case, each datagram selects their paths independently.=

s/each datagram selects their paths/each datagram selects its paths/

>>
>> By default, the traffic load is equally distributed in multiple pa= ths. Other path scheduling

Maybe
s/the traffic load is equally distributed/the traffic load should be equall= y distributed/


>>=C2=A0 mechanisms (e.g., assigning more traffic over better paths) = are also possible and will not impact the interoperability of different imp= lementations.
>
>
> And we will also rephrase the text in section 4.
>
> Let us know if it=E2=80=99s OK for you.
>
> best
>
> Jiazi
>
>
>> On 23 May 2017, at 14:10, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wr= ote:
>>
>> Hi Jiazi,
>>
>> unfortunately, the following sentence is not correct, as basically= any transport can be encapsulated over UDP:
>>
>>> Per-Datagram scheduling is recommended for transport layer pro= tocols that have less constraint on datagram arriving order such as UDP. >>
>> I would propose the following sentence:
>>
>>> Per-Datagram scheduling is only recommended if it is known tha= t the traffic is not sensitive to reordering, e.g. for non-reliable transmi= ssion of media traffic.
>>
>> In this case I would further recommend to add the following senten= ce:
>>
>>> Note that the use of paths with highly different delays can st= ill have a negative impact on these kind of transmissions, as packets that = arrive too late may be ignored and therefore have been transmitted unnecess= arily.
>>
>> Further I also don=E2=80=99t agree to this sentence:
>>
>>> In lossy networks, per-datagram scheduling is also recommended= .
>>
>> Even in lossy networks, per-datagram scheduling is still not recom= mended for TCP (if the delay of the different paths are too diverse).
>>
>> Finally, I would further recommend you to not say that round-robin= needs to be used in section 8.4. I also don=E2=80=99t think you need to ha= ve the two bullet points that explain what per-datagram and per-flow means.= It=E2=80=99s enough to say that per-flow scheduling means that a decision is made on the first packet which path to use and all subs= equent packets of the same flow (e.g. identified by the 5- or 6-tuple) need= to use the same path.
>>
>> Further please also check section 4 as this also makes assumptions= on the path selection.
>>
>> Thanks,
>> Mirja
>>
>>
>>
>>> Am 23.05.2017 um 13:49 schrieb Jiazi Yi <ietf@jiaziyi.com>:
>>>
>>> Dear Mirja,
>>>
>>> Thank very much for your reply.
>>>
>>> We understand your concern on the performance, especially the = issue of packet reordering when the multipath protocol is applied to transp= ort protocol like TCP. Therefore, we propose to have some guidelines to ind= icate when per-flow scheduling is recommended, and when per-packet scheduling is recommended.
>>>
>>> More specifically, in the draft, we propose the text:
>>>
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> In section 1.1, Experiments to be conducted:
>>>
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 Different path-selection schedule= rs. Depending on the application type and transport layer type either per-f= low scheduler or per-datagram scheduler is applied. By default, round-robin= scheduling is used to select a path to be used. In some scenarios, weighted scheduling can be considered: for example, the paths with lower m= etrics (i.e., higher quality) can transfer more datagrams or flows compared= to paths with higher metrics.
>>>
>>>
>>> In section 8.4, Datagram Processing at the MP-OLSRv2 Originato= r
>>>
>>> If a matching Multipath Routing Tuple is obtained, the Path Tu= ples of the Multipath Routing Tuple are applied to the datagrams using roun= d-robin scheduling. The scheduling policy can be either per-flow or per-dat= agram, depending on the transport layer protocol and the application used:
>>>
>>>=C2=A0 =C2=A0 =C2=A0- In per-flow scheduling, the datagrams of = the same flow is transmitted through the same path. Different flows are ass= igned to different paths according to round-robin scheduling. For example, = there are 2 path Tuples (Path-1, Path-2) for the destination router D. A series of flows (Flow-1, Flow-2, Flow-3, ... etc.) are to be s= ent to router D. Path-1 is then chosen for Flow-1, Path-2 for Flow-2, Path-= 1 for Flow 3, etc.
>>>
>>>=C2=A0 =C2=A0 =C2=A0- In per-datagram scheduling, different dat= agrams are transmitted through different paths according to round-robin sch= eduling. For example, there are 2 path Tuples (Path-1, Path-2) for the dest= ination router D. A series of datagrams (Packet-1, Packet-2, Packet-3, ... etc.) are to be sent to router D. Path-1 is then chosen for = Packet-1, Path-2 for Packet-2, Path-1 for Packet 3, etc.
>>>
>>> Per-flow scheduling is recommended for transport layer protoco= ls that require strict ordering of the datagrams such as TCP. By default, p= er-flow scheduling is used. Per-Datagram scheduling is recommended for tran= sport layer protocols that have less constraint on datagram arriving order such as UDP. In lossy networks, per-datagram sc= heduling is also recommended.
>>> Other path scheduling mechanisms are also possible and will no= t impact the interoperability of different implementations.
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> If it looks good for you, we will make the modification in the= next revision of the draft.
>>>
>>> regards
>>>
>>> Jiazi
>>>
>>>
>>>
>>>> On 22 May 2017, at 12:17, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net> wrote:
>>>>
>>>> Hi Jiazi,
>>>>
>>>> sorry for my very late reply. Please see below.
>>>>
>>>>> Am 10.05.2017 um 00:51 schrieb Jiazi Yi <ietf@jiaziyi.com>:
>>>>>
>>>>> Dear Mirja,
>>>>>
>>>>> Thanks very much for your review and comments. Please = find the reply inline:
>>>>>
>>>>>> ---------------------------------------------= -------------------------
>>>>>> DISCUSS:
>>>>>> ---------------------------------------------= -------------------------
>>>>>>
>>>>>> The following text in section 4 seems to indicate = that scheduling is done
>>>>>> on a per-packet basis:
>>>>>> "When there is a
>>>>>> datagram to be sent to a destination, the source r= outer acquires a
>>>>>> path from the Multi-path Routing Set (MAY be Round= -Robin, or other
>>>>>> scheduling algorithms)."
>>>>>> This seems not appropriate as e.g. TCP packets rou= ted on links with
>>>>>> largely different delays may suffer performance. E= CMP usually hashes the
>>>>>> 5-tuple or 6-tuple (incl. DiffServ Codepoint) to s= etup state and routes
>>>>>> all packets belonging to the same flow on the same= route. I recommend to
>>>>>> apply the same here.
>>>>>>
>>>>>> Also related is this text in section 8.4 that shou= ld explain Round-Robin
>>>>>> on a per flow basis instead. Further this should o= nly be an example
>>>>>> scheduling alogirthm while text belong seems to as= sume that Round-Robin
>>>>>> is always used.
>>>>>> "If a matching Multi-path Routing Tuple is ob= tained, the Path Tuples
>>>>>> of the Multi-path Routing Tuple are applied to the= datagrams using
>>>>>> Round-robin scheduling.=C2=A0 For example, there a= re 2 path Tuples
>>>>>> (Path-1, Path-2) for destination router D. A serie= s of datagrams
>>>>>> (Packet-1, Packet-2, Packet-3, ... etc.) are to be= sent router D.
>>>>>> Path-1 is then chosen for Packet-1, Path-2 for Pac= ket-2, Path-1 for
>>>>>> Packet 3, etc.=C2=A0 Other path scheduling mechani= sms are also possible
>>>>>> and will not impact the interoperability of differ= ent
>>>>>> implementations.=E2=80=9D
>>>>>
>>>>> In fact, the per-packet scheduling is an intentional c= hoice because:
>>>>>
>>>>> 1. The aimed scenario is mobile ad hoc networks, which= have high packet loss by nature. One of the most important reasons is rout= e failure due to mobility =E2=80=94 in such case, if a per-flow scheduling = is applied, the whole flow will lost. On the other hand, if we send the packets in disjoint paths (not necessarily equal cost), we = can still make use partial information of the flow, or even reconstruct the= flow with erasure coding. This is especially interesting for video/audio s= treaming.
>>>>
>>>> This is only true for unreliable or partially reliable tra= ffic. I see your use case. However, will if you have TCP traffic, you can p= robably assume that the traffic is reliable and should not route on a per-p= acket basis. This case is not covered in your draft. Also for other non-TCP you often might not know much about the traf= fic characteristics and therefore cannot know if per-packet scheduling is g= ood or bad. Therefore default should be per-flow.
>>>>
>>>>>
>>>>> 2. In such kind of lossy networks, the traditional TCP= performs very poor [1]. So as far as I know, TCP is not very popular in ad= hoc networks. On the other hand, based on our study, the multi-path routin= g can actually reduce the overall jitter [2].
>>>>
>>>> I didn=E2=80=99t have time to read the whole paper but on = a brief look, it looks like you take the delay into account for TCP traffic= . Which is what I said above: either you have two links which have more or = less the same delay or re-ordering will be wrongly interpreted as congestion. The other problem is TCP reduces its sending rate due to lo= ss. So if both links are congested and losses occurred (in a non-synchroniz= ed way), TCP will react to both signals and reduce its sending rate more th= an necessary. That's why I would recommend to schedule TCP as well as other reliable and congestion-control= led traffic on a per-flow base. Further for UDP traffic there is no good wa= y to actually know if the traffic is reliably transmitted and congestion co= ntrol, so it=E2=80=99s hard to make such a decision in the network in a general case.
>>>>
>>>>>
>>>>> We understand your concern on this issue (and you can = imagine that you are not the first one who raises this ;). It is also somet= hing that we want to have further experience from this *experimental* draft= , as we stated in the =E2=80=9Cexperiments to be conducted=E2=80=9D section:
>>>>>
>>>>>=C2=A0 =C2=A0=E2=80=A2 Different path-selection schedul= ers. By default, round-robin scheduling is used to select a path to be used= for datagrams. In some scenarios, weighted scheduling can be considered: f= or example, the paths with lower metrics (i.e., higher quality) can transfer more datagrams compared to paths with higher metrics.
>>>>>=C2=A0 =C2=A0=E2=80=A2 The impacts of the delay variati= on due to multipath routing. [RFC2991] brings out some concerns of multipat= h routing, especially variable latencies. Although current experiment resul= ts show that multipath routing can reduce the jitter in dynamic scenarios, some transport protocols or applications may be sensitive to the datagram = re-ordering.
>>>>>=C2=A0 =C2=A0=E2=80=A2 The disjoint multipath protocol = has interesting application with erasure coding, especially for services li= ke video/audio streaming [WPMC11]. The combination of erasure coding mechan= isms and this extension is thus encouraged.
>>>>
>>>> That=E2=80=99s fine but then you cannot assume in the rest= of the document that per-packet scheduling is used.
>>>>
>>>> There are two options to handle this: either you remove th= e text that is cited above and do not talk about scheduling at all other th= an in the experimentation part, or you explain carefully when potentially p= er-packet scheduling could be used and make clear that by default and especially for TCP per-flow scheduling should be= used.
>>>>
>>>>
>>>>>
>>>>>
>>>>> [1] Performance Evaluation of TCP over Mobile Ad-hoc N= etworks https://arxiv.org/pdf/1002.2189.pdf
>>>>> [2] Multipath optimized link state routing for mobile = ad hoc networks", In Elsevier Ad Hoc Journal, vol.9, n. 1, 28-47, Janu= ary, 2011.
>>>>>
>>>>>>
>>>>>> Related is this text in section 8.4.:
>>>>>> "If datagrams without source routing header n= eed to be forwarded using
>>>>>> multiple paths (for example, based on the informat= ion of DiffServ
>>>>>> Code Point [RFC2474])"
>>>>>> RFC2474 does not specify any application requireme= nts on multipath use
>>>>>> and as such the DiffServe field should not be used= to determine if the
>>>>>> flow can be routed on multiple paths. The ability = to profit from
>>>>>> multipath routing depends not only on the applicat= ion and protocols used
>>>>>> but also on the characteristics of the multipath l= ink(s); so it's hard to
>>>>>> make any implicit assumptions here. However, if ro= uting would only be
>>>>>> recommended on a per-flow basis this problem does = not occur and the
>>>>>> brackets above could be remove. Further, if routed= on a per flow basis
>>>>>> would be done, DiffServ could actually be used to = decide which path to
>>>>>> use, if e.g. one path has a lower delay, but that = seem to need further
>>>>>> discussion as well.
>>>>>
>>>>> As we mentioned before, the multipath routing has spec= ial interests in audio/video streaming applications. For applications that = requires strict ordering, single path can be used. For streaming and time-c= ritical applications, the multi-path application might be more interesting, which can be identified by the DiffServe inform= ation.
>>>>
>>>> Which DiffServ codepoints are you taking about? Some of th= e code points require low delay but they either say nothing about reorderin= g or require a bounded jitter as well which mean forwarding on a per-packet= basis over two links which highly different delays should not be done.
>>>>
>>>> Mirja
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------= -------------------------
>>>>>> COMMENT:
>>>>>> ---------------------------------------------= -------------------------
>>>>>>
>>>>>> Minor comments/questions:
>>>>>>
>>>>>> 1) section 8.4: this sentence is not clear:
>>>>>> "It is RECOMMENDED to use MTU sizes consideri= ng the source routing
>>>>>> header to avoid fragmentation."
>>>>>> MAYBE
>>>>>> "It is NOT RECOMMENDED to fragment the IP pac= ket if the packet with the
>>>>>> source routing header would=C2=A0 exceed the minim= um MTU along the path. In
>>>>>> this case source routing and therefore the additio= nal path calculated by
>>>>>> MP-OLSRv2 SHOULD NOT be used.=E2=80=9D
>>>>>
>>>>> Fixed.
>>>>>
>>>>>>
>>>>>> 2) section 9:
>>>>>> "For IPv6 networks, it MUST
>>>>>>=C2=A0 =C2=A0be set to 0, i.e., no constraint on ma= ximum number of hops."
>>>>>> Why is that?
>>>>>
>>>>> Because the current RFC6554 supports only IPv6 strict = source routing, we thus need to keep all the path information in the source= routing header, in which case we don=E2=80=99t know the number of hops. >>>>>
>>>>> On the other hand, we noticed that the IPv6 segment ro= uting header is being discussed at 6man, we thus have the following text in= the =E2=80=9CExperiments to be conducted=E2=80=9D section:
>>>>>
>>>>>=C2=A0 =C2=A0=E2=80=A2 Use of IPv6 loose source routing= . In the current specification, only strict source routing is used for IPv6= based on [RFC6554]. In [I=E2=80=91D.ietf=E2=80=916man=E2=80=91segment=E2= =80=91routing=E2=80=91header], the use of loose source routing is also= proposed in IPv6. In scenarios where the length of the source routing header is critical, the loose source rout= ing can be considered.
>>>>>
>>>>>>
>>>>>> 3) Not sure why section 12.1. is there? Can this b= e removed?
>>>>>
>>>>> Removed.
>>>>>
>>>>> Agains, we appreciate your valuable comments and hope = that our reply addresses your concern.
>>>>>
>>>>> regards
>>>>>
>>>>> Jiazi
>>>>>
>>>>>>
>>>>>>
>>>>>> _____________________________________________= __
>>>>>> manet mailing list
>>>>>> manet@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>
>
>

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

=C2=A0

This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender.

--001a1137751e3730ea05506ff43c-- From nobody Fri May 26 09:54:25 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A688B128DF6; Fri, 26 May 2017 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsglJSL9AQwv; Fri, 26 May 2017 09:54:21 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F287127909; Fri, 26 May 2017 09:54:21 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id f55so12855026qta.3; Fri, 26 May 2017 09:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y/MlEB6vfo+TDm1Wv4WaWLXlteEtldCpPv9Pdt7gWNc=; b=Z4XagUs5rNsnSbJ6kelfhx6iwuwM20ChSNDW7MF8AxZMch2x02J6FqsNA8fHO67nkD 3P/GrZTqhFJjoEeaPMPb0tdNc/84pUg3UamOL0UQIfpQocdQ6TgxcVRiXVi0QjJzneCJ PfL9a5/QEKQ3SJ5Jf1Md2J+tPHPuAh3UsAQu7WlmQuovvtjM7THKNUeJJJN2KGme4ZkG TPM37MCTcQ+vya0W/78mnbZn0m3h0D0c1OV5b4ghciSrlLEaV5NZznoVa4gkfRXwGL8w 3X7b2Q1dXzGmUW+JwOachB77nNh08khDrUmHPAEa2EyPk+POh+9CFsQr4rrE4JWKpBu4 T+6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y/MlEB6vfo+TDm1Wv4WaWLXlteEtldCpPv9Pdt7gWNc=; b=nJqpCSv32XJGR49sBjs8mLw3QZGWOsqJobEgURrQmp5ml07nX1yqiJT9B3hNy75v04 uUVAwtvHRDsFmdLL1mZiRTQdYyMJz4IUDzImWNREZD8X6Z3lprRdL0sXdP2EbldaBwPG d0SS0Ud9qLgdQWvi+ul6+30tiJDlh9n9iz3D/QlgvSvjQcRWhhi6cubp8jDsW3jiROHh ex2C6aOdGT0rVBu8OeoDE9iuY6edTpo12AjK6xH9p0Zxe7hM7R4imDx8CXHGsxgZ+Te+ LiNn9iplk44D+PDhShMyiCofcB4+EchlwH6bdJLqal2q9+Wg39ZQgE0dM5oQ5WxxZvP8 OekQ== X-Gm-Message-State: AODbwcDoyDb49ymP3lVhG7/JZVp3HX7oGnEctjI7xRMqMlzK2UiIzFqK SfeCd4WLnzOeYUUmGY6ps41Vdg7Xfw== X-Received: by 10.200.39.93 with SMTP id h29mr3612713qth.76.1495817660638; Fri, 26 May 2017 09:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.52 with HTTP; Fri, 26 May 2017 09:54:20 -0700 (PDT) In-Reply-To: <149501966459.6639.7362226295968105924@ietfa.amsl.com> References: <149501966459.6639.7362226295968105924@ietfa.amsl.com> From: Abdussalam Baryun Date: Fri, 26 May 2017 18:54:20 +0200 Message-ID: To: "manet-chairs@tools.ietf.org" Cc: manet , draft-ietf-manet-rfc5444-usage@ietf.org Content-Type: multipart/alternative; boundary="001a113fe3564fab65055070308e" Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 16:54:24 -0000 --001a113fe3564fab65055070308e Content-Type: text/plain; charset="UTF-8" Hi MANET CHairs, IMHO it is strange or maybe very strange that this draft is proposing that standard for protocols that are reactive and proactive protocols but does not distinguish the usage of the standard for each protocol. I ask that the authors edit and make it clear that packet/message format usage depends on if the network is using 1) reactive, 2) proactive, 3) hybrid. We need to discuss each separately, I suggest we make three separate sections for each protocol category. thanks AB On Wed, May 17, 2017 at 1:14 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks of the IETF. > > Title : Rules for Designing Protocols Using the RFC 5444 > Generalized Packet/ Message Format > Authors : Thomas Clausen > Christopher Dearlove > Ulrich Herberg > Henning Rogge > Filename : draft-ietf-manet-rfc5444-usage-06.txt > Pages : 26 > Date : 2017-05-17 > > Abstract: > RFC 5444 specifies a generalized MANET packet/message format and > describes an intended use for multiplexed MANET routing protocol > messages that is mandated to use on the port/protocol specified by > RFC 5498. This document updates RFC 5444 by providing rules and > recommendations for how the multiplexer operates and how protocols > can use the packet/message format. In particular, the mandatory > rules prohibit a number of uses that have been suggested in various > proposals, and which would have led to interoperability problems, to > the impediment of protocol extension development, and to an inability > to use optional generic parsers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-06 > https://datatracker.ietf.org/doc/html/draft-ietf-manet-rfc5444-usage-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-rfc5444-usage-06 > > > 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/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a113fe3564fab65055070308e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi MANET CHairs,

IMHO it=C2= =A0is strange or maybe very strange that this draft is proposing that stand= ard for protocols that are reactive and proactive protocols but does not di= stinguish the usage of the standard for each protocol.=C2=A0
I=C2=A0ask that the authors edit and make it clear that packet/= message format usage depends on if the network is using 1) reactive, 2) pro= active, 3) hybrid. We need to discuss each separately,

I suggest we make three separate sections for each protocol category.=

thanks
AB

On Wed, May 17, 2017 at 1:14 PM, <internet-drafts@ietf.org> wrote:
=
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Mobile Ad-hoc Networks of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Rules for Designing Protocols Using the RFC 5444 Generalized Packet/ Messa= ge Format
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Thom= as Clausen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christopher Dearlove
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ulrich Herberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Henning Rogge
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-rfc5444-usage-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-17

Abstract:
=C2=A0 =C2=A0RFC 5444 specifies a generalized MANET packet/message format a= nd
=C2=A0 =C2=A0describes an intended use for multiplexed MANET routing protoc= ol
=C2=A0 =C2=A0messages that is mandated to use on the port/protocol specifie= d by
=C2=A0 =C2=A0RFC 5498.=C2=A0 This document updates RFC 5444 by providing ru= les and
=C2=A0 =C2=A0recommendations for how the multiplexer operates and how proto= cols
=C2=A0 =C2=A0can use the packet/message format.=C2=A0 In particular, the ma= ndatory
=C2=A0 =C2=A0rules prohibit a number of uses that have been suggested in va= rious
=C2=A0 =C2=A0proposals, and which would have led to interoperability proble= ms, to
=C2=A0 =C2=A0the impediment of protocol extension development, and to an in= ability
=C2=A0 =C2=A0to use optional generic parsers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-manet-rfc5444-usage/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-manet-rfc5444-usage-06
https://datatracker.ietf.org/= doc/html/draft-ietf-manet-rfc5444-usage-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u<= wbr>rl2=3Ddraft-ietf-manet-rfc5444-usage-06


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/

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

--001a113fe3564fab65055070308e-- From nobody Fri May 26 10:05:55 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3AE1294B3; Fri, 26 May 2017 10:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDhq1hSiwJpq; Fri, 26 May 2017 10:05:52 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2848E126B7F; Fri, 26 May 2017 10:05:52 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id w50so911706wrc.0; Fri, 26 May 2017 10:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=nmL6ZT6/bpW9RzQbthLc4LIwM+dfBaRDm9tH2JIn/b0=; b=AcV5hN6NC2K6chnIPMxOJCP0XBiLxs+e39frPPDf1z7TMF9YrkRFTkrKFMG92FUahi NSMTkBEE0j1eamrW/StqRtlrn+ZFqRfMoYDyjjUbt/3avj7fquzkrljyIfXAf9BVTOrw AfwvEZIbXspCCh7wfBCEYyQuztiNybVvd/GbOrntLKfl3FMTYWP2DHRZCerEhtiwaPDI F2kgcJcHD5dpKGVzvBdK0QcPuEzJlHpqheIAVt0OzlM/WzAnlqz2nrnR/nQ2KEbisao0 Gipt4oHimLHAR4jgbRA2E3ZruCcOGSqGE9DYNWSV5gyyvn/PcAXBj/840NUsPyE/T085 EZQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=nmL6ZT6/bpW9RzQbthLc4LIwM+dfBaRDm9tH2JIn/b0=; b=JQMsWRLVU+cIbQQVcmmpHFaRGsZPXLNXDhaQgKEuu1zT+/Xz5RlIBBLAPh3AyXcGgS 6F9wvFsFhlY1nheEiR11CcfXTjCYVja8cR7ApwSCTy47a7MKg4/vD7U7qRFX7vRMgsvX BEIePkEKnA67dWT1bw/H2O2NJw4HTh+0GF30aEvEfc30tMmpYiIp4L/9hOfvtqodcUvy IZzlrf7wA/1Xk/+YJx2IvmQay70UsRP/e+dndhBi/8qRA+7vNJcah0ud8vjDkN1jCYMi J9CKzd/rL5PcGNmPGT3gMGzla7CniThgFelV6fSwCR3/aLB6wGliA3R1RMGEzanxcnue lBSQ== X-Gm-Message-State: AODbwcBg6KC9e8kTY3WF8Nz8KmbPP4jsWM6jH3ZL6Z60sR1MuM9utF6O eLrRa+hU5k7UDg== X-Received: by 10.223.150.12 with SMTP id b12mr2648085wra.149.1495818350669; Fri, 26 May 2017 10:05:50 -0700 (PDT) Received: from [10.2.183.22] (82-132-244-83.dab.02.net. [82.132.244.83]) by smtp.gmail.com with ESMTPSA id 25sm1551215wrz.8.2017.05.26.10.05.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 10:05:50 -0700 (PDT) References: <149501966459.6639.7362226295968105924@ietfa.amsl.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-74381E8C-B242-4996-A4CF-D03689D20EBB Message-Id: <90F5358C-8F41-4746-9D2D-A1B73EFE6044@gmail.com> Cc: "manet-chairs@tools.ietf.org" , draft-ietf-manet-rfc5444-usage@ietf.org, manet X-Mailer: iPhone Mail (14E304) From: Christopher Dearlove Date: Fri, 26 May 2017 18:05:42 +0100 To: Abdussalam Baryun Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-rfc5444-usage-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 17:05:54 -0000 --Apple-Mail-74381E8C-B242-4996-A4CF-D03689D20EBB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable No, it really doesn't. That's the point of RFC 5444, it carries everything. W= here there are specific requirements (which may be more complicated than tha= t split) protocols can, and in some cases are requested to, indicate why the= y do things as they do. And we're also past WG stage too. The WG, which understands this, passed thi= s a time ago. We're at the AD stage, the last couple of edits being for comm= ents from our AD, the wider IESG to follow. -- =20 Christopher Dearlove christopher.dearlove@gmail.com chris@mnemosyne.demon.co.uk is dead > On 26 May 2017, at 17:54, Abdussalam Baryun w= rote: >=20 > Hi MANET CHairs, >=20 > IMHO it is strange or maybe very strange that this draft is proposing that= standard for protocols that are reactive and proactive protocols but does n= ot distinguish the usage of the standard for each protocol.=20 >=20 > I ask that the authors edit and make it clear that packet/message format u= sage depends on if the network is using 1) reactive, 2) proactive, 3) hybrid= . We need to discuss each separately, >=20 > I suggest we make three separate sections for each protocol category. >=20 > thanks > AB >=20 >> On Wed, May 17, 2017 at 1:14 PM, wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >> This draft is a work item of the Mobile Ad-hoc Networks of the IETF. >>=20 >> Title : Rules for Designing Protocols Using the RFC 544= 4 Generalized Packet/ Message Format >> Authors : Thomas Clausen >> Christopher Dearlove >> Ulrich Herberg >> Henning Rogge >> Filename : draft-ietf-manet-rfc5444-usage-06.txt >> Pages : 26 >> Date : 2017-05-17 >>=20 >> Abstract: >> RFC 5444 specifies a generalized MANET packet/message format and >> describes an intended use for multiplexed MANET routing protocol >> messages that is mandated to use on the port/protocol specified by >> RFC 5498. This document updates RFC 5444 by providing rules and >> recommendations for how the multiplexer operates and how protocols >> can use the packet/message format. In particular, the mandatory >> rules prohibit a number of uses that have been suggested in various >> proposals, and which would have led to interoperability problems, to >> the impediment of protocol extension development, and to an inability >> to use optional generic parsers. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-rfc5444-usage/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-manet-rfc5444-usage-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-manet-rfc5444-usage-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc5444-usage-06 >>=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 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-74381E8C-B242-4996-A4CF-D03689D20EBB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No, it really doesn't. That's the poin= t of RFC 5444, it carries everything. Where there are specific requirements (= which may be more complicated than that split) protocols can, and in some ca= ses are requested to, indicate why they do things as they do.

And we're also= past WG stage too. The WG, which understands this, passed this a time ago. W= e're at the AD stage, the last couple of edits being for comments from our A= D, the wider IESG to follow.

--  
Christopher Dearlove
=

On 26 May 2017, at 17= :54, Abdussalam Baryun <abd= ussalambaryun@gmail.com> wrote:

Hi MANET CHairs,

IMHO i= t is strange or maybe very strange that this draft is proposing that st= andard for protocols that are reactive and proactive protocols but does not d= istinguish the usage of the standard for each protocol. 
I ask that the authors edit and make it clear that packet/m= essage format usage depends on if the network is using 1) reactive, 2) proac= tive, 3) hybrid. We need to discuss each separately,

I suggest we make three separate sections for each protocol category.

thanks
AB

On Wed, May 17, 2017 at 1:14 PM, <i= nternet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directori= es.
This draft is a work item of the Mobile Ad-hoc Networks of the IETF.

        Title           : R= ules for Designing Protocols Using the RFC 5444 Generalized Packet/ Message = Format
        Authors         : Thoma= s Clausen
                     =     Christopher Dearlove
                     =     Ulrich Herberg
                     =     Henning Rogge
        Filename        : draft-ietf= -manet-rfc5444-usage-06.txt
        Pages           : 2= 6
        Date            : 2= 017-05-17

Abstract:
   RFC 5444 specifies a generalized MANET packet/message format an= d
   describes an intended use for multiplexed MANET routing protoco= l
   messages that is mandated to use on the port/protocol specified= by
   RFC 5498.  This document updates RFC 5444 by providing rul= es and
   recommendations for how the multiplexer operates and how protoc= ols
   can use the packet/message format.  In particular, the man= datory
   rules prohibit a number of uses that have been suggested in var= ious
   proposals, and which would have led to interoperability problem= s, to
   the impediment of protocol extension development, and to an ina= bility
   to use optional generic parsers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-manet-rfc5444-usage/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-manet-rfc5444-usage-06
https://datatracker.ietf.org/d<= wbr>oc/html/draft-ietf-manet-rfc5444-usage-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc5444-usage-06


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/

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

____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-74381E8C-B242-4996-A4CF-D03689D20EBB-- From nobody Mon May 29 05:12:25 2017 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B04129548; Mon, 29 May 2017 05:12:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-manet-olsrv2-multipath@ietf.org, aretana@cisco.com, Stan Ratliff , manet-chairs@ietf.org, sratliff@idirect.net, manet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149605993681.17697.4174820450373714864.idtracker@ietfa.amsl.com> Date: Mon, 29 May 2017 05:12:16 -0700 Archived-At: Subject: [manet] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-manet-olsrv2-multipath-15=3A_=28with_COMMENT=29?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 12:12:17 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-manet-olsrv2-multipath-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and my comments! From nobody Tue May 30 08:57:44 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987A7129AA3 for ; Tue, 30 May 2017 08:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txUM__mdJTH6 for ; Tue, 30 May 2017 08:57:41 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CF61296CF for ; Tue, 30 May 2017 08:57:40 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 30 May 2017 16:57:16 +0100 From: Rick Taylor To: "manet@ietf.org" Thread-Topic: New DLEP Extension draft Thread-Index: AQHS2V1o4na7p10PxkWhcBJR2BRTCg== Date: Tue, 30 May 2017 15:57:17 +0000 Message-ID: <1496159837.3129.8.camel@tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [manet] New DLEP Extension draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:57:42 -0000 SGkgQWxsLA0KDQpJIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBkcmFmdCBETEVQIGV4dGVuc2lvbiB0 byB0cnkgdG8gd29yayBhcm91bmQgc29tZQ0Kb2YgdGhlIHByb2JsZW1zIGFzc29jaWF0ZWQgd2l0 aCBpbXBsZW1lbnRpbmcgRExFUCBvbiBtb2RlbXMgdGhhdCBkbyBub3QNCm9wZXJhdGUgb3ZlciBh IHNpbmdsZSBMYXllciAyIGRvbWFpbiwgc3VjaCBhcyBMVEUsIFdpRmkgQVBzLCBhbmQgV0FODQpy YWRpb3MuwqANCg0KUGxlYXNlIGNhbiB5b3UgaGF2ZSBhIGxvb2ssIGFzIEknbSBsb29raW5nIGZv ciBXRyBhZG9wdGlvbi4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt ZGxlcC1saWQvDQoNCkNoZWVycywNCg0KUmljaw0K From nobody Tue May 30 11:01:17 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12D6129AEB for ; Tue, 30 May 2017 11:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=inf-net-nl.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRnOvCOQN-rj for ; Tue, 30 May 2017 11:01:13 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7230C124217 for ; Tue, 30 May 2017 11:01:12 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 7so98340700wmo.1 for ; Tue, 30 May 2017 11:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inf-net-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fwx0ZEyZox5ogeIDdHkT5J41tVvNXow4A737qZ7KPHk=; b=NpGP/DR+q3kwdLZn+VRU/qY5uc13bAiD2VwfuaUcrSXNaXWBy9NnKrmlyx+EK/OFxE jnRMpCMAmh1gf5Qt1xUtrr8O9pRsmeQ9RrmDaRmBYMBX5RmDOxyLu6SZpGFcXxQ6K+Ta AEDe50WgZ6f3yhN7bkEUapks6nGqeurhrM74zRGpjbkWn7EW3xxnJr1yhuR7gnkHB45W YTyFl5jVQVaPgFeFUO4t+s0v60DL/vj+Fqa63hKwrCm9eT2c7m27B6Usl57ChLh3QfvR 9/gB7g1ZdpktzAJZxuwUfq7gozfio7+Y4SjB+2sSWm8AEi/Ej3Ht5NU7kxGFtGTOWQ1F BwPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fwx0ZEyZox5ogeIDdHkT5J41tVvNXow4A737qZ7KPHk=; b=Wnw+3uNvFyna8S9ZhXhVFQJwc0c20puBpC24nj3syvKyI4dzUivoUlHViGCqgcPIJ4 Tqmpls1lLSDtJp5G01c0la1ewBN0L9zD5/nFzGB12o6yQD21CSSncchHHdUfVs5hg1yX OH7xmnhh4mMD0s3bFjc9Hhye/idhFLE9SWvIV3vXRbx8S3GoNuGX6v/phKRItiYFaxkk M4prW4MyUszoQ0vKPZfouGR9U+djDeJNaqMXKRlIFy7unWdh+8gqG4/Fqnx+oYf2z5S1 94GOe892BpNQ1SE+absnPpuXrc3WcSQTKyU2CryPB9fBIu2/WZOZBnXzRgpVSTlwOG6b 4UYw== X-Gm-Message-State: AODbwcDp7AYCGBqZLI2gLe1w5Ry0U8qXo+r9ijRKtAOAzJPQTX5onhME aKD9akI9vJru/ZH5XnVCkA== X-Received: by 10.80.184.226 with SMTP id l89mr17981315ede.137.1496167271239; Tue, 30 May 2017 11:01:11 -0700 (PDT) Received: from ipv6.dynamic.ziggo.nl ([2001:1c01:300:4d00:48fa:52de:f388:ba76]) by smtp.gmail.com with ESMTPSA id n55sm4683447edd.65.2017.05.30.11.01.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 30 May 2017 11:01:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Teco Boot In-Reply-To: <1496159837.3129.8.camel@tropicalstormsoftware.com> Date: Tue, 30 May 2017 20:01:08 +0200 Cc: "manet@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1496159837.3129.8.camel@tropicalstormsoftware.com> To: Rick Taylor X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [manet] New DLEP Extension draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 18:01:16 -0000 Rick, I think your proposed extension enlarges applicability of DLEP. So I = support your efforts. I wonder why you don't suggest an IP Destination prefix (or even = Source+Destination prefixes, to support SADR) as ID. In many cases the = ID would be a default route. For backbone edge routers, metrics to = nearby destinations would differ from far destinations. I know this opens a discussion towards route distribution. But let that = be out of scope, the main purpose is to provide link metrics (or path = metrics, if we are at layer-3). I don't get how your proposal helps in the multi-hop layer-2 use case. = AFAIR it is up to such a sub-IP layer to provide MAC end-to-end link = metrics. I understand the difficulties, as current multi-hop sub-IP = stuff typically do not support required functions. Teco > Op 30 mei 2017, om 17:57 heeft Rick Taylor = het volgende geschreven: >=20 > Hi All, >=20 > I have just submitted a draft DLEP extension to try to work around = some > of the problems associated with implementing DLEP on modems that do = not > operate over a single Layer 2 domain, such as LTE, WiFi APs, and WAN > radios.=20 >=20 > Please can you have a look, as I'm looking for WG adoption. >=20 > https://datatracker.ietf.org/doc/draft-dlep-lid/ >=20 > Cheers, >=20 > Rick > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue May 30 11:25:24 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126231293FF for ; Tue, 30 May 2017 11:25:22 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT_RJ0nVJmQv for ; Tue, 30 May 2017 11:25:20 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0743126D73 for ; Tue, 30 May 2017 11:25:19 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 30 May 2017 19:24:55 +0100 From: Rick Taylor To: Teco Boot CC: "manet@ietf.org" Thread-Topic: [manet] New DLEP Extension draft Thread-Index: AQHS2W65vr6S32fDDkGFr5sULdofrqINLHmg Date: Tue, 30 May 2017 18:24:51 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801C4283CE1@tss-server1.home.tropicalstormsoftware.com> References: <1496159837.3129.8.camel@tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] New DLEP Extension draft X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 18:25:22 -0000 (Top posting in Outlook, sorry) Hi Teco, Thanks for the support! I didn't choose IP destination and prefix as the identifier, as we already = support multiple IP addresses and subnets per destination dynamically, so I= wanted one consistent number that wasn't related and was static for the se= ssion. In some modems that I'm aware of some bits of the subnet is often t= he node id, but I want to keep it more general. I think the route distribution door is already ajar with DLEP Attached Subn= ets, but I don't think I'm opening it any wider. If I was going to extend = subnets into full routing I would suggest another extension including Sourc= e, Priority and Via IP addresses which are missing from core-DLEP. I wasn't trying to address the multiple layer-2 hops problem in general, ju= st address a few common cases: 1) Access Points: E.g. "The Internet is this way, the link is up and at X M= bps" 2) WAN Radios: E.g. "I can get traffic to 10.0/16 via Y, but don't expect E= thernet frames end-to-end" As I see it, both use-cases can use this extension without adding lots of c= omplexity, and it can work in parallel with the existing DLEP implementatio= ns. Cheers, Rick -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 30 May 2017 19:01 To: Rick Taylor Cc: manet@ietf.org Subject: Re: [manet] New DLEP Extension draft Rick, I think your proposed extension enlarges applicability of DLEP. So I suppor= t your efforts. I wonder why you don't suggest an IP Destination prefix (or even Source+Des= tination prefixes, to support SADR) as ID. In many cases the ID would be a = default route. For backbone edge routers, metrics to nearby destinations wo= uld differ from far destinations. I know this opens a discussion towards route distribution. But let that be = out of scope, the main purpose is to provide link metrics (or path metrics,= if we are at layer-3). I don't get how your proposal helps in the multi-hop layer-2 use case. AFAI= R it is up to such a sub-IP layer to provide MAC end-to-end link metrics. I= understand the difficulties, as current multi-hop sub-IP stuff typically d= o not support required functions. Teco > Op 30 mei 2017, om 17:57 heeft Rick Taylor het volgende geschreven: >=20 > Hi All, >=20 > I have just submitted a draft DLEP extension to try to work around=20 > some of the problems associated with implementing DLEP on modems that=20 > do not operate over a single Layer 2 domain, such as LTE, WiFi APs,=20 > and WAN radios. >=20 > Please can you have a look, as I'm looking for WG adoption. >=20 > https://datatracker.ietf.org/doc/draft-dlep-lid/ >=20 > Cheers, >=20 > Rick > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue May 30 12:41:48 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE08129431 for ; Tue, 30 May 2017 12:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1qtawUMOAht for ; Tue, 30 May 2017 12:41:45 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E341250B8 for ; Tue, 30 May 2017 12:41:45 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id j17so57735661uag.3 for ; Tue, 30 May 2017 12:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qH+kVAmaWhPKbepvGD5EWyUrjsKvfQ5AEJ7K1yfxmbg=; b=ko5hcZ3GBbLZC24KZBtt/6trEFXZ7Onsy/zGG2LjUyTrUaKFJTd2s0H9HGw0HtsXFQ 09nKegCsgyCsdMp4GO5RRO0DE8ShMSqqlUwgLNCrCtV/2APl3DBK/nqg+jswcmq0uEOr aDtfjrkgwpq1wwy0JsuALPSt8m6Ps7zDn+f8yFILWpK6XNhVXudBHhHZ23H7RnY0sgJX jHiWg+jnrCPkY55bK5WBiBWbYh46Fa///EKO3g+2P1KglAyW3ckrxjv0aGDLr4mh8kBD yhvnYT8E9gew3ozBDo9PGgUS1ktlcQ3DZfExhhPftnUIIxOHVrcT3wHwUXI9r0f6RhSH y0NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qH+kVAmaWhPKbepvGD5EWyUrjsKvfQ5AEJ7K1yfxmbg=; b=ScED1G0zgKZX1d0IHx/CwYIhvHO5VPUk90jJYeW49uEPVcGvEZ6s0AWAa43QSfw0QJ rD/dKq5gxqFEkmttmWnlK+rMqvikBHGJlbDciK96ehVGPoAPqAWgE0lVsl35/8KTPcTy RdEEmZDECbE/x8a8ITYMxXK+u8wwG0FDEVvErejOiKsEX8BOjnC4bZR3/TV0ZiV4sOKq KGgalwtK87e7ILOINDk8vrvbe/Ri+OeiQMWfzqmdhA5CTJ8sW1B/UBprpIeuEp+LzP4O fKwaAvLElfQzMaV+JYW9KWKA421t4FueQy7ALQHwGEqNW0FdORy8zFpb/Nw0mZZHrjUT gVXQ== X-Gm-Message-State: AODbwcBsvvsf40XsIPzflS2D3JvScTRQrG/LeBCLNZFRiSkBdRjF9WOo av4ZHVL645smscR2whhwBrsCKYt3oB3f X-Received: by 10.159.60.100 with SMTP id w36mr11262697uah.31.1496173304650; Tue, 30 May 2017 12:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.50.7 with HTTP; Tue, 30 May 2017 12:41:44 -0700 (PDT) From: Justin Dean Date: Tue, 30 May 2017 15:41:44 -0400 Message-ID: To: "manet@ietf.org" Content-Type: multipart/alternative; boundary="f403043646b458a93f0550c2fe54" Archived-At: Subject: [manet] No MANET meeting planed for Prague X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 19:41:47 -0000 --f403043646b458a93f0550c2fe54 Content-Type: text/plain; charset="UTF-8" Due to the lack of new work being discussed on list (excepting the DLEP extensions just mentioned 2 hours prior to this email....), the chairs have decided to not schedule a MANET meeting during the next IETF meeting in Prague. Justin Dean --f403043646b458a93f0550c2fe54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Due to the lack of new work being discussed on list (excep= ting the DLEP extensions just mentioned 2 hours prior to this email....), t= he chairs have decided to not schedule a MANET meeting during the next IETF= meeting in Prague.

Justin Dean
--f403043646b458a93f0550c2fe54-- From nobody Tue May 30 14:56:30 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4C3127F0E for ; Tue, 30 May 2017 14:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHezQjYFrUyG for ; Tue, 30 May 2017 14:56:27 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC211201F2 for ; Tue, 30 May 2017 14:56:26 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 30 May 2017 22:56:02 +0100 From: Rick Taylor To: Justin Dean , "manet@ietf.org" Thread-Topic: [manet] No MANET meeting planed for Prague Thread-Index: AQHS2XzJAcMLsGnOIkGEXO7WRvobRKINaq4w Date: Tue, 30 May 2017 21:56:00 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801C4285129@tss-server1.home.tropicalstormsoftware.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801C4285129tssserver1hom_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] No MANET meeting planed for Prague X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 21:56:30 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F9801C4285129tssserver1hom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGFybuKApiBJIHdhcyBqdXN0IHRyeWluZyB0byBraWNrIG9mZiBzb21lIGRpc2N1c3Npb27igKYN Cg0KSW4gd2hpY2ggY2FzZSBjb3VsZCB3ZSBzY2hlZHVsZSBhbiBpbnRlcmltIGZhaXJseSBwcm9t cHRseSwgcHJlZmVyYWJseSBiZWZvcmUgUHJhZ3VlPyAgU29tZSBvZiB1cyBhcmUgc3RpbGwgYXR0 ZW5kaW5nIGFuZCBpdCBnaXZlcyB1cyBhIGNoYW5jZSB0byBkaXNjdXNzIGFueXRoaW5nIHJlbGV2 YW50IGZhY2UgdG8gZmFjZS4NCg0KSSBiZWxpZXZlIHRoZXJlIGlzIHN0aWxsIERMRVAgQ3JlZGl0 IFdpbmRvd2luZy9GbG93IENvbnRyb2wgZXh0ZW5zaW9ucyB0byBkaXNjdXNzLCBhbmQgSSBoYXZl ICh5ZXQpIGFub3RoZXIgZXh0ZW5zaW9uIGluIHByb2dyZXNzLg0KDQpBcmUgdGhlcmUgYW55IG5v bi1ETEVQIE1BTkVUIHRvcGljcz8gIE11bHRpY2FzdD8NCg0KUmljaw0KDQpGcm9tOiBtYW5ldCBb bWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gRGVhbg0K U2VudDogMzAgTWF5IDIwMTcgMjA6NDINClRvOiBtYW5ldEBpZXRmLm9yZw0KU3ViamVjdDogW21h bmV0XSBObyBNQU5FVCBtZWV0aW5nIHBsYW5lZCBmb3IgUHJhZ3VlDQoNCkR1ZSB0byB0aGUgbGFj ayBvZiBuZXcgd29yayBiZWluZyBkaXNjdXNzZWQgb24gbGlzdCAoZXhjZXB0aW5nIHRoZSBETEVQ IGV4dGVuc2lvbnMganVzdCBtZW50aW9uZWQgMiBob3VycyBwcmlvciB0byB0aGlzIGVtYWlsLi4u LiksIHRoZSBjaGFpcnMgaGF2ZSBkZWNpZGVkIHRvIG5vdCBzY2hlZHVsZSBhIE1BTkVUIG1lZXRp bmcgZHVyaW5nIHRoZSBuZXh0IElFVEYgbWVldGluZyBpbiBQcmFndWUuDQoNCkp1c3RpbiBEZWFu DQo= --_000_38A5475DE83986499AEACD2CFAFC3F9801C4285129tssserver1hom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBsYW5nPUVOLUdCIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2Vj dGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGFybuKApiBJ IHdhcyBqdXN0IHRyeWluZyB0byBraWNrIG9mZiBzb21lIGRpc2N1c3Npb27igKY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPkluIHdoaWNoIGNhc2UgY291bGQgd2Ugc2NoZWR1bGUgYW4gaW50ZXJpbSBmYWly bHkgcHJvbXB0bHksIHByZWZlcmFibHkgYmVmb3JlIFByYWd1ZT/CoCBTb21lIG9mIHVzIGFyZSBz dGlsbCBhdHRlbmRpbmcgYW5kIGl0IGdpdmVzIHVzIGEgY2hhbmNlIHRvIGRpc2N1c3MgYW55dGhp bmcgcmVsZXZhbnQgZmFjZSB0byBmYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBiZWxpZXZlIHRo ZXJlIGlzIHN0aWxsIERMRVAgQ3JlZGl0IFdpbmRvd2luZy9GbG93IENvbnRyb2wgZXh0ZW5zaW9u cyB0byBkaXNjdXNzLCBhbmQgSSBoYXZlICh5ZXQpIGFub3RoZXIgZXh0ZW5zaW9uIGluIHByb2dy ZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXJlIHRoZXJlIGFueSBub24tRExFUCBNQU5FVCB0b3Bp Y3M/wqAgTXVsdGljYXN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UmljazxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBtYW5ldCBbbWFpbHRvOm1hbmV0 LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIERlYW48YnI+PGI+ U2VudDo8L2I+IDMwIE1heSAyMDE3IDIwOjQyPGJyPjxiPlRvOjwvYj4gbWFuZXRAaWV0Zi5vcmc8 YnI+PGI+U3ViamVjdDo8L2I+IFttYW5ldF0gTm8gTUFORVQgbWVldGluZyBwbGFuZWQgZm9yIFBy YWd1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RHVlIHRvIHRoZSBsYWNrIG9mIG5ldyB3 b3JrIGJlaW5nIGRpc2N1c3NlZCBvbiBsaXN0IChleGNlcHRpbmcgdGhlIERMRVAgZXh0ZW5zaW9u cyBqdXN0IG1lbnRpb25lZCAyIGhvdXJzIHByaW9yIHRvIHRoaXMgZW1haWwuLi4uKSwgdGhlIGNo YWlycyBoYXZlIGRlY2lkZWQgdG8gbm90IHNjaGVkdWxlIGEgTUFORVQgbWVldGluZyBkdXJpbmcg dGhlIG5leHQgSUVURiBtZWV0aW5nIGluIFByYWd1ZS48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5KdXN0aW4gRGVhbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9k eT48L2h0bWw+ --_000_38A5475DE83986499AEACD2CFAFC3F9801C4285129tssserver1hom_-- From nobody Wed May 31 06:53:04 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FD5129438 for ; Wed, 31 May 2017 06:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqZBfX-aVMu6 for ; Wed, 31 May 2017 06:30:38 -0700 (PDT) Received: from mlbxsmtp03.harris.com (mlbxsmtpout03.harris.com [192.52.234.95]) by ietfa.amsl.com (Postfix) with ESMTP id 9C38B1289B0 for ; Wed, 31 May 2017 06:30:38 -0700 (PDT) X-AuditID: c034ea5e-eebff70000001ea3-37-592ec57d9916 Received: from MLBXCH19.cs.myharris.net ( [10.64.224.137]) by mlbxsmtp03.harris.com (mail) with SMTP id FC.68.07843.D75CE295; Wed, 31 May 2017 09:30:37 -0400 (EDT) Received: from MLBXCH18.cs.myharris.net (10.64.224.136) by MLBXCH19.cs.myharris.net (10.64.224.137) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 31 May 2017 09:30:36 -0400 Received: from MLBXCH18.cs.myharris.net ([10.64.224.162]) by MLBXCH18.cs.myharris.net ([10.64.224.162]) with mapi id 15.00.1263.000; Wed, 31 May 2017 09:30:36 -0400 From: "Morgan, Keith" To: "manet@ietf.org" Thread-Topic: Mail regarding draft-dlep-lid Thread-Index: AdLaEhVjbxwzcZvASRi0De17cHVqkQ== Date: Wed, 31 May 2017 13:30:35 +0000 Message-ID: <63448cdd41fa4c94a44a390dd10848a1@MLBXCH18.cs.myharris.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.64.248.68] Content-Type: multipart/alternative; boundary="_000_63448cdd41fa4c94a44a390dd10848a1MLBXCH18csmyharrisnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42LhcnjQqVt7VC/S4NNFCYt/W56wOzB6LFny kymAMYrLJiU1J7MstUjfLoEro/fvfuaCadoVF19NY29gfKXaxcjJISFgItHxdR97FyMXh5DA UkaJvUeXQjk7GCUeP1/KBuGsYJToOTOfCaSFTUBbYv/6NWwgtoiAqsSP35vYQWxhATWJZXvf sULEtSUerb4EVaMn0dPzgRHEZhFwklg19Q0bhK0q8ebYDrBeXgF3iQ/LFoH1MgrISnxpXM0M YjMLiEvcegKxV0JAQGLJnvPMELaoxMvH/1ghbAOJrUv3sUDYChLHD0LcxiyQK/H+20smiPmC EidnPmGZwCgyC8nYWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRXNzkiqK c0sKDIz1MhKLijKL9ZLzczcxAuPogMmruB2Mq1/ZH2IU4GBU4uHtqNCNFGJNLCuuzD3EKMHB rCTCu+CwXqQQb0piZVVqUX58UWlOavEhRmkOFiVxXnVboJRAemJJanZqakFqEUyWiYNTqoGx 9kud8l+OxFWmghNmzvrawjg7429YsUTetev5zxOjt+rurmM/5iFicflJSIb9FPmrR+9lRu/f aPQkQ+5kQ7+8psX/Fzs2MTUX7w//2/dKI+haqW9j18u9K6a6ZVufkL3+YKLS8dlVxr93GZzn uPH1JL9M7u65n5e7pfe/eGt143+G3EOx+Vs2KbEUZyQaajEXFScCAMcsu4yfAgAA Archived-At: X-Mailman-Approved-At: Wed, 31 May 2017 06:53:04 -0700 Subject: [manet] Mail regarding draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 13:30:40 -0000 --_000_63448cdd41fa4c94a44a390dd10848a1MLBXCH18csmyharrisnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been reviewing the proposed Link Identifier Extension to DLEP and ha= ve the following comments: The focus of the proposal appears to be to enable Routers to identify where= they cannot reach Destinations via the MAC address provided in the Destina= tion Up message. This would be the case with our Modem. Our current implementation does use "sleight-of-hand" and will report both = the MAC address and IP address in the Destination Up message, however the D= estination is only reachable via its IP address. The concept proposed appears sound; my immediate suggestion would be to rec= ommend a length of 6 bytes for the identifier, this would allow the Modem t= o use the MAC address of the destination which should ensure uniqueness whi= le allowing the router to determine how to address packets to the Destinati= on based on the use of the Link Identifier Data Item. Regards Keith --_000_63448cdd41fa4c94a44a390dd10848a1MLBXCH18csmyharrisnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have been reviewing the proposed Link Identifier E= xtension to DLEP and have the following comments:

 

The focus of the proposal appears to be to enable Ro= uters to identify where they cannot reach Destinations via the MAC address = provided in the Destination Up message. This would be the case with our Mod= em.

 

Our current implementation does use “sleight-o= f-hand” and will report both the MAC address and IP address in the De= stination Up message, however the Destination is only reachable via its IP = address.

 

The concept proposed appears sound; my immediate sug= gestion would be to recommend a length of 6 bytes for the identifier, this = would allow the Modem to use the MAC address of the destination which shoul= d ensure uniqueness while allowing the router to determine how to address packets to the Destination based on= the use of the Link Identifier Data Item.

 

 

Regards

 = ;

Kei= th

--_000_63448cdd41fa4c94a44a390dd10848a1MLBXCH18csmyharrisnet_-- From nobody Wed May 31 07:57:27 2017 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC72129C07 for ; Wed, 31 May 2017 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH9wGQNNnxKn for ; Wed, 31 May 2017 07:57:24 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C25129B1D for ; Wed, 31 May 2017 07:57:23 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 31 May 2017 15:56:59 +0100 From: Rick Taylor To: "kmorga07@harris.com" , "manet@ietf.org" Thread-Topic: [manet] Mail regarding draft-dlep-lid Thread-Index: AQHS2h4n8gQUpl33xUaMr+5MGkcJ5A== Date: Wed, 31 May 2017 14:56:59 +0000 Message-ID: <1496242619.3129.19.camel@tropicalstormsoftware.com> References: <63448cdd41fa4c94a44a390dd10848a1@MLBXCH18.cs.myharris.net> In-Reply-To: <63448cdd41fa4c94a44a390dd10848a1@MLBXCH18.cs.myharris.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Mail regarding draft-dlep-lid X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:57:26 -0000 SGkgS2VpdGgsDQoNCkNvbW1lbnRzIGlubGluZS4uLg0KDQpPbiBXZWQsIDIwMTctMDUtMzEgYXQg MTM6MzAgKzAwMDAsIE1vcmdhbiwgS2VpdGggd3JvdGU6DQo+IEhlbGxvLA0KPiDCoA0KPiBJIGhh dmUgYmVlbiByZXZpZXdpbmcgdGhlIHByb3Bvc2VkIExpbmsgSWRlbnRpZmllciBFeHRlbnNpb24g dG8gRExFUA0KPiBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KDQpUaGFua3MgZm9y IHRoZSBxdWljayByZXZpZXchDQoNCj4gwqANCj4gVGhlIGZvY3VzIG9mIHRoZSBwcm9wb3NhbCBh cHBlYXJzIHRvIGJlIHRvIGVuYWJsZSBSb3V0ZXJzIHRvIGlkZW50aWZ5DQo+IHdoZXJlIHRoZXkg Y2Fubm90IHJlYWNoIERlc3RpbmF0aW9ucyB2aWEgdGhlIE1BQyBhZGRyZXNzIHByb3ZpZGVkIGlu DQo+IHRoZSBEZXN0aW5hdGlvbiBVcCBtZXNzYWdlLiBUaGlzIHdvdWxkIGJlIHRoZSBjYXNlIHdp dGggb3VyIE1vZGVtLg0KPiDCoA0KPiBPdXIgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBkb2VzIHVz ZSDigJxzbGVpZ2h0LW9mLWhhbmTigJ0gYW5kIHdpbGwgcmVwb3J0DQo+IGJvdGggdGhlIE1BQyBh ZGRyZXNzIGFuZCBJUCBhZGRyZXNzIGluIHRoZSBEZXN0aW5hdGlvbiBVcCBtZXNzYWdlLA0KPiBo b3dldmVyIHRoZSBEZXN0aW5hdGlvbiBpcyBvbmx5IHJlYWNoYWJsZSB2aWEgaXRzIElQIGFkZHJl c3MuDQoNClRoaXMgaXMgb25lIG9mIHRoZSB1c2UtY2FzZXMgSSB3YXMgdHJ5aW5nIHRvIGZpeCwg c28gSSdtIGdsYWQgaXQgaGVscHMuDQoNCj4gwqANCj4gVGhlIGNvbmNlcHQgcHJvcG9zZWQgYXBw ZWFycyBzb3VuZDsgbXkgaW1tZWRpYXRlIHN1Z2dlc3Rpb24gd291bGQgYmUNCj4gdG8gcmVjb21t ZW5kIGEgbGVuZ3RoIG9mIDYgYnl0ZXMgZm9yIHRoZSBpZGVudGlmaWVyLCB0aGlzIHdvdWxkIGFs bG93DQo+IHRoZSBNb2RlbSB0byB1c2UgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSBkZXN0aW5hdGlv biB3aGljaCBzaG91bGQNCj4gZW5zdXJlIHVuaXF1ZW5lc3Mgd2hpbGUgYWxsb3dpbmcgdGhlIHJv dXRlciB0byBkZXRlcm1pbmUgaG93IHRvDQo+IGFkZHJlc3MgcGFja2V0cyB0byB0aGUgRGVzdGlu YXRpb24gYmFzZWQgb24gdGhlIHVzZSBvZiB0aGUgTGluaw0KPiBJZGVudGlmaWVyIERhdGEgSXRl bS4NCg0KNCBpcyBvbmx5IFJFQ09NTUVOREVELiDCoEFzIGEgdmFyaWFibGUgbGVuZ3RoIGZpZWxk LCBMaW5rIElkJ3MgY2FuIGJlDQphbnkgbGVuZ3RoLCBzbyBpZiB5b3Ugd2FudCB0byB1c2UgNiwg dGhhdCdzIGZpbmUuIMKgSSBvbmx5IHBpY2tlZCA0IGFzIEkNCmltYWdpbmVkIHBlb3BsZSBoYWQg aW50ZWdlciB2YWx1ZXMgYW5kIGZlbHQgSSBoYWQgdG8gcmVjb21tZW5kDQpzb21ldGhpbmcgdG8g cG9pbnQgcGVvcGxlIGF3YXkgZnJvbSB1c2luZyBTSEExIGhhc2hlcyBvciBzb21ldGhpbmcgaHVn ZQ0KKGFsdGhvdWdoIHRoZXkgc3RpbGwgY2FuKS4NCg0KSXQncyBpbnRlcmVzdGluZyB0aGF0IHlv dXIgTGluayBJZHMgYWN0dWFsbHkgYXJlIE1BQ3MsIGJ1dCBieSB1c2luZw0KTGluayBJZHMgbm90 IE1BQyBBZGRyZXNzIERhdGEgSXRlbXMgeW91IGFyZSBiZWluZyBleHBsaWNpdCB0aGF0IHRoZQ0K TUFDcyBjYW4ndCBiZSB1c2VkIGluIGZyYW1lcy4gwqBJIGhhZG4ndCB0aG91Z2h0IG9mIHRoaXMg dXNlLWNhc2UsIGJ1dA0KSSdtIGdsYWQgaXQgd29ya3MgZm9yIHlvdSENCg0KT25lIHRoaW5nIHRo YXQgaXMgcHJvYmFibHkgbWlzc2luZyBpcyBhIHJlcXVpcmVtZW50IHRoYXQgYWxsIExpbmsgSWRz DQpzaG91bGQgYmUgdGhlIHNhbWUgbGVuZ3RoIGR1cmluZyBhIHNlc3Npb24uIMKgRG8gcGVvcGxl IHRoaW5rIHRoaXMgaXMgYQ0KdmFsaWQgcmVzdHJpY3Rpb24/DQoNCkNoZWVycywNCg0KUmljaw0K