From nobody Thu Sep 1 07:06:21 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF82312DA26; Thu, 1 Sep 2016 07:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssrmT03es2Lp; Thu, 1 Sep 2016 07:06:15 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D9012DAD8; Thu, 1 Sep 2016 06:53:39 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 93so42150721qtg.2; Thu, 01 Sep 2016 06:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=sIUa6mLLznHv23oZubKe00JUyd4Wb9Lu0K4+6TtyPr0=; b=HUlgMTYVG7ScEYoZ/CnL9mSYODfbnb8clRSjp36gQIFjIzZkpFH4BNbjZmoAlnhLyn 6xIZniRWqwEAeJ8CT3HtbA3Au5HgU7X2f+Xva8wSPoXkJSckWbagBrYZpJa/fMTkJx4e 9aro8frnSK2nHjt4guc8leywPkrkZET9Q9N8GL4FsBWLvPPRE7vR3N8cpdSg5bKYiBn+ e3QyzNXSPXy70WDiiQIg4kCWWI5UAsSUn9kYjBlm9Vl7kM3HcZkcNETSHmZg2ix/ltCr QwlM30BuR0OOYn8iVqoX96Ow37wFC7/8HdoeyNv8t+2zx37w6nxo62hattito1V4AzX+ LjMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=sIUa6mLLznHv23oZubKe00JUyd4Wb9Lu0K4+6TtyPr0=; b=Gt6QKxY09YjIBoWRYeqR4DfEscgYs9RXc/dAQX6QiT6lfbU2NGhSpknVmqQ8DIyh4Y 899OwAtLbDd3plg0p2TNdN7EQtGus+a0p7n9IRHOft85oVoozfOnp5bp4La/0Tr0HeIu w/KoP6sefE4rSQLEzxpp+9wFWdmRSSUE0PCUlsDeCtP4PzGYOu7UlI7Lxit/8AT1nJXF DNv7LVLzVKsxytt6Tp3Z+QTaOQbOFPxuTUiYwj3eZbEBF0EBVQrzlAeeTmYJg40y/iZh uTmJhxMGf+x1eOL6mmVLEeRvyS64PkE3AmdN5PEkwloTVIcLPXkTn+cuLzJbqo4PAtjD Z1CA== X-Gm-Message-State: AE9vXwMBD6kTogBudQX1+YMSTS3WKHddckvv5ulsRNaNACGcS9HvXFtk6n3HgYt0Utb/VKhh37U0NEpprMZzJw== X-Received: by 10.237.46.6 with SMTP id j6mr17755615qtd.113.1472738019086; Thu, 01 Sep 2016 06:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.102 with HTTP; Thu, 1 Sep 2016 06:53:08 -0700 (PDT) From: Henning Rogge Date: Thu, 1 Sep 2016 15:53:08 +0200 Message-ID: To: Susan Hares , Jon Hudson , haoweiguo@huawei.com, Donald Eastlake , liyizhou@huawei.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rtg-dir@ietf.org, trill@ietf.org Subject: [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 14:06:19 -0000 Hi, Jonathan Hardwick asked me to review the initial revision of the TRILL Address Flush draft. I can easily see the use case for this functionality with TRILL aware RBridges that have additional knowledge about leaving (or even "roaming" end-devices). The speedup for removing the MAC addresses could be essential for performance in some scenarios. I have a couple of comments and questions to chapter 2: - is it a normal use case to have "n" nicknames and "m" VLAN blocks and want to remove all combinations of all of them or do you expect on of the list to have size 1 normally? - I would suggest moving the description of each "TLV" for the Address Flush Message into a sub-chapter. This allows to break the "wall of text" for each TLV and makes adding a small ascii-art for each TLV possible, making the TLVs much easier to read and to reference (see below). - the difference between the "VLAN Block Case" (2.1) and "Extensible Case" (2.2) feels artificial. Why not add a "VLAN block TLV", which contains the list of VLAN start/end fields? - maybe the Nicknames could also be moved into a TLV, allowing to process the whole message with a single TLV based parser. - I would suggest adding a new IANA registry to the draft to contain the TLV types. This will make it easier to add types in later IETF documents. Example for new (sub)chapter for TLVs: Chapter x.y: Address Flush Message TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | TLV Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 octet type field Length: length of the TLV data in octets without Type and Length field. TLV Data: TLV specific data Chapter x.y.1: Nickname TLV +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length | Nickname 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname 2 | Nickname K-nicks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Nickname TLV contains a list of Nicknames the Address Flush Message refers to. The length of the Nickname TLV is always an even number of octets. Chapter x.y.2: VLAN block TLV ... Henning Rogge Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From nobody Fri Sep 2 02:32:35 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7289512D7EB; Fri, 2 Sep 2016 02:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 AasydIxp-hj3; Fri, 2 Sep 2016 02:32:26 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 BFEDC12D7E4; Fri, 2 Sep 2016 02:32:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.191.218; From: "Susan Hares" To: "'Henning Rogge'" , "'Jon Hudson'" , , "'Donald Eastlake'" , References: In-Reply-To: Date: Fri, 2 Sep 2016 05:31:19 -0400 Message-ID: <0b9901d204fc$c30aa490$491fedb0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKvIcvkkOn453bl+mp2pk/forV9RJ6rtaBQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, trill@ietf.org Subject: Re: [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 09:32:29 -0000 Henning: Thank you for the review of this draft. The authors (Weiquo, Donald and = Yizhou) will be in touch with you shortly. Donald has been on travel = for 2 weeks - so his response may be early next week.=20 Sue=20 -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Henning = Rogge Sent: Thursday, September 1, 2016 9:53 AM To: Susan Hares; Jon Hudson; haoweiguo@huawei.com; Donald Eastlake; = liyizhou@huawei.com Cc: rtg-dir@ietf.org; trill@ietf.org Subject: [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00 Hi, Jonathan Hardwick asked me to review the initial revision of the TRILL = Address Flush draft. I can easily see the use case for this functionality with TRILL aware = RBridges that have additional knowledge about leaving (or even "roaming" = end-devices). The speedup for removing the MAC addresses could be = essential for performance in some scenarios. I have a couple of comments and questions to chapter 2: - is it a normal use case to have "n" nicknames and "m" VLAN blocks and = want to remove all combinations of all of them or do you expect on of = the list to have size 1 normally? - I would suggest moving the description of each "TLV" for the Address = Flush Message into a sub-chapter. This allows to break the "wall of = text" for each TLV and makes adding a small ascii-art for each TLV = possible, making the TLVs much easier to read and to reference (see = below). - the difference between the "VLAN Block Case" (2.1) and "Extensible = Case" (2.2) feels artificial. Why not add a "VLAN block TLV", which = contains the list of VLAN start/end fields? - maybe the Nicknames could also be moved into a TLV, allowing to = process the whole message with a single TLV based parser. - I would suggest adding a new IANA registry to the draft to contain the = TLV types. This will make it easier to add types in later IETF = documents. Example for new (sub)chapter for TLVs: Chapter x.y: Address Flush Message TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | TLV Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1 octet type field Length: length of the TLV data in octets without Type and Length = field. TLV Data: TLV specific data Chapter x.y.1: Nickname TLV +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length | Nickname 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname 2 | Nickname K-nicks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Nickname TLV contains a list of Nicknames the Address Flush Message = refers to. The length of the Nickname TLV is always an even number of octets. Chapter x.y.2: VLAN block TLV ... Henning Rogge Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr = Kommunikation, Informationsverarbeitung und Ergonomie FKIE = Kommunikationssysteme (KOM) Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, = Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From nobody Fri Sep 2 07:00:49 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7215A12D8AD; Fri, 2 Sep 2016 07:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 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.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oP5e_Liz2Me6; Fri, 2 Sep 2016 07:00:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F33312D7D9; Fri, 2 Sep 2016 07:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1303; q=dns/txt; s=iport; t=1472824841; x=1474034441; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=ZrLaCFmCuHNy4lTqyLJsIggaYSg/1fN8fE4fImy4Gq8=; b=Fis/hxjDaJRLXThY2zpFqJV8perll+dqeQVS0EyIBQaVcJCey4dmjn6r JqY4Uyuzq045YsL7pIkV0dsSWH3dpuWvORVlBUcP7M8o7E4yZ8wKQW1SQ OUHDRz2H1ISCxtN6xpxj04Nywc4jqgez31dw2khS46QO76wn19MeS5LU4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJBQCMhMlX/xbLJq1cg1ABAQEBAXV8A?= =?us-ascii?q?aJ/DAEBAQEBAQUBgRCUCoICJIV4ghMUAQIBAQEBAQEBXieFC1YvBgImAmAtiC8?= =?us-ascii?q?OrwGMSgEBAQEGAQEBAQEBIYEFhGKCQIoXK4IvBZlThiGJFYFuToQQgzSFWYxLg?= =?us-ascii?q?3oeNoQ/OjWGWAEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,271,1470700800"; d="scan'208";a="687526492" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2016 14:00:38 +0000 Received: from ams-iwijnand-88111.cisco.com (ams-iwijnand-88111.cisco.com [10.60.202.92]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u82E0cBO028779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Sep 2016 14:00:38 GMT From: IJsbrand Wijnands Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Sep 2016 16:00:37 +0200 Message-Id: <1675911D-6E27-477E-A040-FA29C95847C8@cisco.com> To: bess-chairs@ietf.org, draft-ietf-bess-evpn-overlay@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: rtg-dir@ietf.org, bess@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-bess-evpn-overlay X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 14:00:45 -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 = =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-bess-evpn-overlay=20 Reviewer: IJsbrand Wijnands=20 Review Date: 02-09-2016 Intended Status: Standards Track Summary:=20 This document is basically ready for publication. Comments: For somebody who is not following this technology in great detail I = found this interesting and educational to read (ok, I had to read it a = couple of times ;-). The document is well written and seems to document = the solution in enough detail. Major Issues:=20 No major issues found. Minor Issues:=20 No minor issues found. Thx, Ice.= From nobody Sat Sep 3 13:16:01 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35BF12B05E; Sat, 3 Sep 2016 13:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cG7lQ9YkzgG2; Sat, 3 Sep 2016 13:15:59 -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 58E4112B015; Sat, 3 Sep 2016 13:15:59 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id q42so146473352uaq.1; Sat, 03 Sep 2016 13:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BRKVXB2DDaneDqns7WpzFWwFYMEaRUC1JUIuix8ktbk=; b=gWT0tOloVBYYrpZFTR7rkymVWVZIYoIF9SDDVaNHUWdE3EPD6059FjieFSyHwZo0vC QuhqneXdfMcoRs007Qm3y1J1sx70zpZfas9UatIs02gBxVxBoeVGCpx0JNv/ZTzg0OGB KCb5HDfVfbACzMbkoIErrJX4N/sEhtvcJsU21uG8ryg4M6PHqdHAf0HIGwOeR8GFRN4Z OCAVR491qP3DWKRqZI9SNxUnOBVydhyweM/Tjm8ZXOIUfGHmGmRX2gExENpqxnnsCGba 6YtGNpdBmiEe0sNgTYskoByHe9mJx/2MQslPCp35X/Zi2lbuj2ohxP7QEmzwp0sEHV6T ySrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BRKVXB2DDaneDqns7WpzFWwFYMEaRUC1JUIuix8ktbk=; b=l6/rlkzlmKdPcGRY3M8Y5UOkWZERirlZp123wI7HM6EjC7VM0wuNMqk7ZhpkFKf/JJ 5icEc5J42pcgSSuDgAPmVkdgMlrFKKSu8xZAFu65bKsI8ou31RRmEw9BFm9BSOBZpNPf aHSUHdIvckXHX/80bzfowCdOiHEDSqdSI3PxLBZzqpFY936l2fjTtyQprStkpMgK53mJ SzhVRVbdJ4OIgBGH96QIX7s5c5G0aqwSfCv5bp8wwDmNh2xHcic5TIda2iY+Za4xPRhA rc9a9Hp26AUwacmrgGOIyY8yGuQzNeVr9dvWCzfe4gd+OwlJOInOhjb7Ki51eKsyTm9J kkqg== X-Gm-Message-State: AE9vXwNV5D38X6jrUvoItaLIidVcG1mUVUkZ8eVl55Z7ClDmCZQZqidjzEbjY7iGv6Tnnev7tlP3bValHEszmg== X-Received: by 10.159.39.6 with SMTP id a6mr17824540uaa.33.1472933758317; Sat, 03 Sep 2016 13:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.97.67 with HTTP; Sat, 3 Sep 2016 13:15:42 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Sat, 3 Sep 2016 16:15:42 -0400 Message-ID: To: Henning Rogge Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtg-dir@ietf.org" , Susan Hares , "trill@ietf.org" , Hao Weiguo , Li Yizhou , Jon Hudson Subject: Re: [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 20:16:01 -0000 Hi, On Thu, Sep 1, 2016 at 9:53 AM, Henning Rogge wrote: > > Hi, > > Jonathan Hardwick asked me to review the initial revision of the TRILL > Address Flush draft. > > I can easily see the use case for this functionality with TRILL aware > RBridges that have additional knowledge about leaving (or even > "roaming" end-devices). The speedup for removing the MAC addresses > could be essential for performance in some scenarios. > > > > I have a couple of comments and questions to chapter 2: > > - is it a normal use case to have "n" nicknames and "m" VLAN blocks > and want to remove all combinations of all of them or do you expect on > of the list to have size 1 normally? I think the most common case will be where some topology change or reconfiguration at the edge of a TRILL campus moves a set of VLANs from one edge RBridge serving the end stations in those VLANs to a different RBridge. Whether the set of VLANs would be one or a few or many blocks just depends on how contiguous the VLAN IDs are. Since this case typically involves one RBridge, one nickname will be common; however, an RBridge can hold multiple nicknames and a RBridge might use multiple nicknames as ingress nickname if it is supporting active-active end station connection as specified RFC 7781 so 2 or more nicknames is entirely plausible. > - I would suggest moving the description of each "TLV" for the Address > Flush Message into a sub-chapter. This allows to break the "wall of > text" for each TLV and makes adding a small ascii-art for each TLV > possible, making the TLVs much easier to read and to reference (see > below). I assume you are refering to the Types in Section 2.2. That seems like a reasonable suggestion. > - the difference between the "VLAN Block Case" (2.1) and "Extensible > Case" (2.2) feels artificial. Why not add a "VLAN block TLV", which > contains the list of VLAN start/end fields? As I recall this was in order to make the VLAN Block case closer to, for convenience, an existing implemented address flush RBridge channel message (using one of the "Private Use" RBridge Channel message protocol numbers) that only applies to VLAN blocks. I'll see what people think about merging the cases. > - maybe the Nicknames could also be moved into a TLV, allowing to > process the whole message with a single TLV based parser. I can see making a common TLV format for all the non-nickname lists but I'm not sure there is much advantage to doing so for nicknames. > - I would suggest adding a new IANA registry to the draft to contain > the TLV types. This will make it easier to add types in later IETF > documents. OK. > Example for new (sub)chapter for TLVs: > > > Chapter x.y: Address Flush Message TLVs > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | TLV Data... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 1 octet type field > Length: length of the TLV data in octets without Type and Length field. > TLV Data: TLV specific data > > > > Chapter x.y.1: Nickname TLV > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (TBD) | Length | Nickname 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Nickname 2 | Nickname K-nicks | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The Nickname TLV contains a list of Nicknames the Address Flush > Message refers to. > > The length of the Nickname TLV is always an even number of octets. > > > > Chapter x.y.2: VLAN block TLV > > ... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Henning Rogge > > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From nobody Mon Sep 5 15:34:52 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2069112B0B4; Mon, 5 Sep 2016 15:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giEm2y-U9Pbm; Mon, 5 Sep 2016 15:34:47 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0082.outbound.protection.outlook.com [104.47.42.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 729E012B0C2; Mon, 5 Sep 2016 15:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e41B5PqDl/k693CVJ3n1XLvplVq33gN4wmeCRZEPLN0=; b=Oub4ODs9Owq/eIa9knW+eHOa1LRkFa7uTKOQqpAclEb+XJjWYelmXFV0o/CFWV/qKrat3HTOJGIu3QIuPrNyvcwK94O6FG5pPOJFf1AQz7uMAsgyQg1wnCtn/ByhmPMliiMtmxJehujC2zRNxVzSJnrcOUsyv+iPt/cTXIiMGqo= Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0264.namprd18.prod.outlook.com (10.163.72.154) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Mon, 5 Sep 2016 22:34:45 +0000 Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0599.016; Mon, 5 Sep 2016 22:34:44 +0000 From: Keyur Patel To: "bess-chairs@ietf.org" , "bess@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [bess] RTG Dir QA review: draft-ietf-bess-evpn-overlay-04.txt Thread-Index: AQHSB8Gs2FQD5hIOJ0qWQD+BeJeuuA== Date: Mon, 5 Sep 2016 22:34:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [73.241.11.75] x-ms-office365-filtering-correlation-id: 593998c7-8846-453b-bb5f-08d3d5dcd5fb x-microsoft-exchange-diagnostics: 1; BY2PR18MB0264; 6:phJWoX+VOhi338cZ6Xj3p0gRcjyKmC4Q3LctJaF0BiOufmFS2G5QZdlqRvA186/SmySBOp6m2ElYSD8guiTaqbtnTLXCnM5OYybMGstqLZnobzswxNIMbWl4NdNvHjDwPV8z4LtXKY9iLUKh4d+revVp4nwbsfVhwbQBLmZ314xYp7Zb3kzNo0gTTCve8r+CYx3cLvY5+1+NI5DbXI4b12E/D1eXz4RBmOZqzhOOXvx1jzT8ifvWucfaLiHY4ZB74Cr87X3MBeM+tCnXE3DMaB+qMNvYfuQM63uak1k9+ojSZFG2xUtJN7whlY92e3Cc; 5:MuZserjKL8BCCm75pMh6gyO+YimhiS5zDwWadXfqDHbo0mDAeUREaG2KCKe9OT8FPe2/pz0c5jx6sim/PDHkWJvrUl6XnJGXZYBnAMtufKN/1PagiASG/thcSWvOxXZoIKsbKPic4cBrgKc0+LzP8Q==; 24:dwt7DN+ahxvPhM+jE0vEuKpzzgg4azxy1aAaBEszqNL1HO1XY062HGIAexfMo6HjEsMR88VuyVqlXPGEbfJBkO908O2FJ/eSd3nM9LRcWyc=; 7:LcsUrcglqKzHXD/4aKy6Y54bWR4QGAkmlu8GISOqNdBWhftbwYEnmFxtTlbqGeCGcST52B5no2tLzaag/wnQEZSe+2h7tKWe9pv7K/JjsarHRyw19ujmD47QOWvPJ7t02hDyMOdViTyoTO40+KAAmUhagKKz4Cz5b15EZP2g+63EgU8zxDqausWzvcE6PDqFshz10DF+EB1NklYiyGAZVSOoME6Iv8rYYO62rxiNpNopjIF5wzFPanUh4r5AQo7W x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR18MB0264; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6043046)(6042046); SRVR:BY2PR18MB0264; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0264; x-forefront-prvs: 005671E15D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(57704003)(66066001)(2906002)(19627595001)(87936001)(7736002)(7846002)(19627405001)(2900100001)(54356999)(50986999)(17760045003)(3280700002)(16236675004)(3660700001)(122556002)(18206015028)(99936001)(2201001)(86362001)(68736007)(76576001)(101416001)(19625215002)(229853001)(33656002)(106356001)(10400500002)(105586002)(106116001)(230783001)(81156014)(81166006)(8936002)(74316002)(189998001)(107886002)(2501003)(8676002)(99286002)(450100001)(77096005)(102836003)(6116002)(586003)(3846002)(97736004)(9686002)(5001770100001)(5002640100001)(5660300001)(19580395003)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0264; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2016 22:34:43.8318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0264 Archived-At: Subject: [RTG-DIR] [bess] RTG Dir QA review: draft-ietf-bess-evpn-overlay-04.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 22:34:50 -0000 --_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: multipart/alternative; boundary="_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_" --_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IFFBIHJldmlld2VyIGZvciBkcmFmdC1pZXRmLWJlc3MtZXZwbi1vdmVybGF5LTA0LnR4dC4NCg0K DQpUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBRQSByZXZpZXdzIGFyZSBpbnRlbmRlZCB0byBiZSBh IHN1cHBvcnQgdG8gaW1wcm92ZSB0aGUgcXVhbGl0eSBvZiBSVEcgQXJlYSBkb2N1bWVudHMgYXMg dGhleSBwYXNzIHRocm91Z2ggdGhlIElFVEYgcHJvY2Vzcy4gVGhpcyBpcyB0aGUgUUEgcmV2aWV3 IGF0IHRoZSB0aW1lIG9mIHRoZSBXRyBkb2N1bWVudCBhZG9wdGlvbiBwb2xsLg0KDQoNClN1bW1h cnk6DQoNCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IEV0aGVybmV0IFZQTiAoRVZQTikg W1JGQzc0MzJdIGNhbiBiZSB1c2VkIGFzIGEgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBPdmVybGF5 IChOVk8pIHNvbHV0aW9uIGFuZCBleHBsb3JlcyB0aGUgdmFyaW91cyB0dW5uZWwgZW5jYXBzdWxh dGlvbiBvcHRpb25zIG92ZXIgSVAgYW5kIHRoZWlyIGltcGFjdCBvbiB0aGUgRVZQTiBjb250cm9s LXBsYW5lIGFuZCBwcm9jZWR1cmVzLiBJbiBwYXJ0aWN1bGFyLCB0aGUgZm9sbG93aW5nIGVuY2Fw c3VsYXRpb24gb3B0aW9ucyBhcmUgYW5hbHl6ZWQ6IFZYTEFOLCBOVkdSRSwgYW5kIE1QTFMgb3Zl ciBHUkUuDQoNCg0KDQpUaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuLCBlYXN5IHRvIHJlYWQg YW5kIGZvbGxvdy4gU29tZSBtaW5vciBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93Og0KDQoNCkNv bW1lbnRzOg0KDQoNCjEpIEludHJvZHVjdGlvbiBzZWN0aW9uIHN1Z2dlc3RzIHhtcHAgYmFzZWQg YXBwcm9hY2ggYXMgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlIEJHUCBhcyBhIGNvbnRyb2wgcGxhbmUu IEl0IGlzIHVuY2xlYXIgaG93IHRoZSBkcmFmdCBzZWN0aW9ucyA4LTEwIGFuZCB0aGUgc2VjdXJp dHkgc2VjdGlvbiAxMiByZWxhdGUgdG8gdGhlIGFsdGVybmF0aXZlIHNvbHV0aW9uLiBNeSBzdWdn ZXN0aW9uIHdvdWxkIGJlIHRvIHJlbW92ZSB0aGUgcmVmZXJlbmNlIGlmIHBvc3NpYmxlIGNvbnNp ZGVyaW5nIHRoZSBkcmFmdCBpcyBzcGVjaWZpYyB0byBCR1AgYXMgYSBjb250cm9sIHBsYW5lLg0K DQoNCjIpIFNlY3Rpb24gNS4xLjIuMSBkZWZpbmVzIEF1dG9kZXJpdmF0aW9uIFJUIHdoaWNoIHN1 Z2dlc3RzIHRoZSB1c2Ugb2YgMiBieXRlIEFTIG51bWJlci4gRG8gd2UgbmVlZCB0byBjb25zaWRl ciA0IGJ5dGUgQVMgbnVtYmVyIGFzIHdlbGw/IFvwn5iKXQ0KDQoNCjMpIFNlY3Rpb24gNjogTWlu b3IgTml0LiBDb25zaWRlciByZXBsYWNpbmcgInN0YXRpY2FsbHkiIHdpdGggImxvY2FsbHkiLg0K DQoNCjQpIFNlY3Rpb24gNy4xOiBUYWxrcyBhYm91dCB1c2luZyBSRCB2YWx1ZSBvZiAwLiBSRCBh cyBhIHR5cGU6dmFsdWUgZmllbGQuIFR5cGUgMCBSRCByZXF1aXJlcyB0aGUgdXNhZ2Ugb2YgMiBi eXRlIEFTIG51bWJlciAocHJpdmF0ZSB2YWx1ZXMgYXJlIHN0cm9uZ2x5IGRpc2NvdXJhZ2VkKSB3 aGljaCBuZWVkcyB0byBiZSAwIGZvciBSRCB2YWx1ZSB0byBiZSAwLiBBUyAwIGFjY29yZGluZyB0 byBJQU5BIGlzIHJlc2VydmVkLiBTZWVtcyB0byBiZSBsaWtlIHVzYWdlIG9mIEFTIDAgaXMgcHJv aGliaXRlZC4gV291bGQgYSByZXNlcnZlIFJEIHZhbHVlIGJlIG1vcmUgYXBwcm9wcmlhdGU/DQoN Cg0KNSkgc2VjdGlvbiA4LjMuMSBkZXNjcmliZXMgdGhlIGRyYWZ0IGNvbnN0cmFpbiB3cnQgbXBs cyBvdmVyIGdyZSB2ZXJzdXMgdnhsYW4vbnZncmUuIFBlcmhhcHMgaXQgd291bGQgYmUgZ3JlYXQg dG8gaGlnaGxpZ2h0IHRoZSBjb25zdHJhaW4gdXBmcm9udCBpbiB0aGUgaW50cm9kdWN0aW9uIHNl Y3Rpb24/DQoNCg0KNikgRG8geW91IG5lZWQgdG8gYWRkIHRleHQgdG8gZGVzY3JpYmUgQVJQL05E IHN1cHByZXNzaW9uIGluIHByZXNlbmNlIG9mIGRlZmF1bHQgcm91dGU/DQoNCg0KQmVzdCBSZWdh cmRzLA0KDQpLZXl1cg0K --_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7YmFja2dyb3Vu ZC1jb2xvcjojRkZGRkZGO2ZvbnQtZmFtaWx5OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMt c2VyaWY7Ij4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBt YXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5 OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweDsgbGlu ZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6 IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij5IZWxsbywKCkkgaGF2ZSBiZWVuIHNl bGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIFFBIHJldmlld2VyIGZvciA8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxZW07IGZvbnQtd2VpZ2h0OiBib2xkOyI+ZHJhZnQtaWV0Zi1iZXNz LWV2cG4tb3ZlcmxheS0wNC50eHQuPC9zcGFuPjxicj4KClRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IFFBIHJldmlld3MgYXJlIGludGVuZGVkIHRvIGJlIGEgc3VwcG9ydCB0byBpbXByb3ZlIHRoZSBx dWFsaXR5IG9mIFJURyBBcmVhIGRvY3VtZW50cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCB0aGUgSUVU RiBwcm9jZXNzLiBUaGlzIGlzIHRoZSBRQSByZXZpZXcgYXQgdGhlIHRpbWUgb2YgdGhlIFdHIGRv Y3VtZW50IGFkb3B0aW9uIHBvbGwuPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9 Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRl cjogMHB4OyBmb250LWZhbWlseTogQ291cmllciwgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBm b250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBpbmhlcml0OyB2ZXJ0aWNhbC1hbGlnbjogYmFz ZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PGJy PjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6 IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5l LWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPlN1bW1hcnk6PC9wcmU+DQo8cHJlIGNs YXNzPSJ3b3Jkd3JhcCIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBmb250LWZhbWlseTogQ291cmllciwgJ0NvdXJp ZXIgTmV3JywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7IGxpbmUtaGVpZ2h0OiBpbmhlcml0 OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd29yZC13 cmFwOiBicmVhay13b3JkOyI+PGJyPjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxl PSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3Jk ZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsg Zm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJh c2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPlRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBFdGhlcm5ldCBWUE4gKEVWUE4pIFtSRkM3NDMyXSBj YW4gYmUgdXNlZCBhcyBhIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gT3ZlcmxheSAoTlZPKSBzb2x1 dGlvbiBhbmQgZXhwbG9yZXMgdGhlIHZhcmlvdXMgdHVubmVsIGVuY2Fwc3VsYXRpb24gb3B0aW9u cyBvdmVyIElQIGFuZCB0aGVpciBpbXBhY3Qgb24gdGhlIEVWUE4gY29udHJvbC1wbGFuZSBhbmQg cHJvY2VkdXJlcy4gSW4gcGFydGljdWxhciwgdGhlIGZvbGxvd2luZyBlbmNhcHN1bGF0aW9uIG9w dGlvbnMgYXJlIGFuYWx5emVkOiBWWExBTiwgTlZHUkUsIGFuZCBNUExTIG92ZXIgR1JFLjwvcHJl Pg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJp ZXIsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdo dDogaW5oZXJpdDsgdmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdy YXA7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPiA8L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFw IiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBw eDsgYm9yZGVyOiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25v c3BhY2U7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFs aWduOiBiYXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7Ij5UaGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuLCBlYXN5IHRvIHJlYWQgYW5kIGZvbGxv dy4gU29tZSBtaW5vciBjb21tZW50cyBhcmUgbGlzdGVkIGJlbG93OjwvcHJlPg0KPHByZSBjbGFz cz0id29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsg cGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1mYW1pbHk6IENvdXJpZXIsICdDb3VyaWVy IE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMnB4OyBsaW5lLWhlaWdodDogaW5oZXJpdDsg dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsiPjxicj48L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVy OiAwcHg7IGZvbnQtZmFtaWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZv bnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IHZlcnRpY2FsLWFsaWduOiBiYXNl bGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij5Db21t ZW50czogPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9Im1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBmb250LWZh bWlseTogQ291cmllciwgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBmb250LXNpemU6IDEycHg7 IGxpbmUtaGVpZ2h0OiBpbmhlcml0OyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PHByZSBzdHlsZT0iZm9udC1z aXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48L3By ZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJv dHRvbTogMHB4OyI+MSkgSW50cm9kdWN0aW9uIHNlY3Rpb24gc3VnZ2VzdHMgeG1wcCBiYXNlZCBh cHByb2FjaCBhcyBhbiBhbHRlcm5hdGl2ZSB0byB0aGUgQkdQIGFzIGEgY29udHJvbCBwbGFuZS4g SXQgaXMgdW5jbGVhciBob3cgdGhlIGRyYWZ0IHNlY3Rpb25zIDgtMTAgYW5kIHRoZSBzZWN1cml0 eSBzZWN0aW9uIDEyIHJlbGF0ZSB0byB0aGUgYWx0ZXJuYXRpdmUgc29sdXRpb24uIE15IHN1Z2dl c3Rpb24gd291bGQgYmUgdG8gcmVtb3ZlIHRoZSByZWZlcmVuY2UgaWYgcG9zc2libGUgY29uc2lk ZXJpbmcgdGhlIGRyYWZ0IGlzIHNwZWNpZmljIHRvIEJHUCBhcyBhIGNvbnRyb2wgcGxhbmUuPC9w cmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1i b3R0b206IDBweDsiPjxicj48L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdp bi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+MikgU2VjdGlvbiA1LjEuMi4xIGRlZmlu ZXMgQXV0b2Rlcml2YXRpb24gUlQgd2hpY2ggc3VnZ2VzdHMgdGhlIHVzZSBvZiAyIGJ5dGUgQVMg bnVtYmVyLiBEbyB3ZSBuZWVkIHRvIGNvbnNpZGVyIDQgYnl0ZSBBUyBudW1iZXIgYXMgd2VsbD8g PGltZyBjbGFzcz0iRW1vamlJbnNlcnQiIGlkPSJPV0FFbW9qaTIyNjI0OSIgYWx0PSLwn5iKIiBz dHlsZT0idmVydGljYWwtYWxpZ246IGJvdHRvbTsiIHNyYz0iY2lkOmYwOWQxODM1LTNlZWItNDZm Zi1iZGMyLWYzOWUzNzMwZGYxYSI+IDwvcHJlPjxwcmUgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48YnI+PC9wcmU+PHByZSBzdHls ZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsi PjMpIFNlY3Rpb24gNjogTWlub3IgTml0LiBDb25zaWRlciByZXBsYWNpbmcgJnF1b3Q7c3RhdGlj YWxseSZxdW90OyB3aXRoICZxdW90O2xvY2FsbHkmcXVvdDsuPC9wcmU+PHByZSBzdHlsZT0iZm9u dC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48 L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyI+NCkgU2VjdGlvbiA3LjE6IFRhbGtzIGFib3V0IHVzaW5nIFJEIHZhbHVl IG9mIDAuIFJEIGFzIGEgdHlwZTp2YWx1ZSBmaWVsZC4gVHlwZSAwIFJEIHJlcXVpcmVzIHRoZSB1 c2FnZSBvZiAyIGJ5dGUgQVMgbnVtYmVyIChwcml2YXRlIHZhbHVlcyBhcmUgc3Ryb25nbHkgZGlz Y291cmFnZWQpIHdoaWNoIG5lZWRzIHRvIGJlIDAgZm9yIFJEIHZhbHVlIHRvIGJlIDAuIEFTIDAg YWNjb3JkaW5nIHRvIElBTkEgaXMgcmVzZXJ2ZWQuIFNlZW1zIHRvIGJlIGxpa2UgdXNhZ2Ugb2Yg QVMgMCBpcyBwcm9oaWJpdGVkLiBXb3VsZCBhIHJlc2VydmUgUkQgdmFsdWUgYmUgbW9yZSBhcHBy b3ByaWF0ZT8gPC9wcmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsiPjxicj48L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6 IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+NSkgc2VjdGlvbiA4 LjMuMSBkZXNjcmliZXMgdGhlIGRyYWZ0IGNvbnN0cmFpbiB3cnQgbXBscyBvdmVyIGdyZSB2ZXJz dXMgdnhsYW4vbnZncmUuIFBlcmhhcHMgaXQgd291bGQgYmUgZ3JlYXQgdG8gaGlnaGxpZ2h0IHRo ZSBjb25zdHJhaW4gdXBmcm9udCBpbiB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24/PC9wcmU+PHBy ZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsiPjxicj48L3ByZT48cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+NikgRG8geW91IG5lZWQgdG8gYWRkIHRleHQgdG8g ZGVzY3JpYmUgQVJQL05EIHN1cHByZXNzaW9uIGluIHByZXNlbmNlIG9mIGRlZmF1bHQgcm91dGU/ IDwvcHJlPjxwcmUgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAwcHg7Ij48YnI+PC9wcmU+PHByZSBzdHlsZT0iZm9udC1zaXplOiAxM3B4OyBt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiPkJlc3QgUmVnYXJkcyw8L3ByZT48 cHJlIHN0eWxlPSJmb250LXNpemU6IDEzcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRv bTogMHB4OyI+S2V5dXI8L3ByZT48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_-- --_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_ Content-Type: image/png; name="=?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?=" Content-Description: =?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?= Content-Disposition: inline; filename="=?utf-8?B?T3V0bG9va0Vtb2ppLfCfmIoucG5n?="; size=488; creation-date="Mon, 05 Sep 2016 22:13:05 GMT"; modification-date="Mon, 05 Sep 2016 22:13:05 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABMAAAATCAYAAAByUDbMAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAYpJREFUeNpi/P//PwO1ACM2wf9njBWAVD4QBwCxApLUAyDeAMQTGU3O PkDRA3QUIxaD+oFUAREOaQQa2IDTMKBB84FUAgk+WwA0MBFmGBOaixJIDKYEoD6465igBjkge+3C rW94TUCTr4eGMdxl8TCZxMYHDIZR1xk2HPiA1SCQOEgepA4J5CMbFgAPhM1vwfTFW9+xGgYTh6lD 1s8IdKIAkH4PEz1w9jOYVpBiZ1CQZMMw7MHzXwwPnv0Esx2MeRESxmcYWYCUAbJiFAVYAMgCbJbA vPmAWjmACZqS4aHdOOs5wdgEBcWE5a8Y0HIGPAIOwETtjXkYJqIqxAAgeQM1ThTzkQ2biB5mC7a8 xZ7kgeICvMzoYTsRJaMDY3U9chIBpaMHz34xxPsKgwMcFIsLgckB5KL+YllkgyYAg6oQJW9Ck8h+ 5NgFhd3GAx/humAGI2cGIHYEGvYBW0YHGTgf2YX4MjkQF4IMwlkEIeXVfByGwsqzAwTLMywGg7wN cvED9AIR3TCAAAMAqh+p+YMVeBQAAAAASUVORK5CYII= --_004_SN1PR18MB0270C4F8E72682398E1726FDC1E60SN1PR18MB0270namp_-- From nobody Tue Sep 6 23:19:26 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E682512B0E3; Tue, 6 Sep 2016 23:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 AYVeoX7gLYNb; Tue, 6 Sep 2016 23:19:18 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B92A12B0DC; Tue, 6 Sep 2016 23:19:17 -0700 (PDT) Received: from rufsun5.fkie.fraunhofer.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1bhWCY-0003pU-7E; Wed, 07 Sep 2016 08:19:14 +0200 Received: from srv-mail-01.fkie.fraunhofer.de ([128.7.11.16] helo=srv-mail-01.gaia.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1bhWCY-0000YD-43; Wed, 07 Sep 2016 08:19:14 +0200 Received: from srv-mail-02.gaia.fkie.fraunhofer.de (128.7.11.17) by srv-mail-01.gaia.fkie.fraunhofer.de (128.7.11.16) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 7 Sep 2016 08:19:13 +0200 Received: from [10.71.67.24] (128.7.89.212) by srv-mail-02.gaia.fkie.fraunhofer.de (128.7.11.17) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 7 Sep 2016 08:19:13 +0200 From: Henning Rogge To: Donald Eastlake , Henning Rogge References: Message-ID: Date: Wed, 7 Sep 2016 08:19:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [128.7.89.212] X-ClientProxiedBy: srv-mail-01.gaia.fkie.fraunhofer.de (128.7.11.16) To srv-mail-02.gaia.fkie.fraunhofer.de (128.7.11.17) X-Virus-Scanned: yes (ClamAV 0.98.1/22199/Wed Sep 7 01:36:53 2016) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 380fbaf250fdfd2c99b0a646ce1041f1 Archived-At: Cc: "rtg-dir@ietf.org" , Susan Hares , "trill@ietf.org" , Hao Weiguo , Li Yizhou , Jon Hudson Subject: Re: [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 06:19:21 -0000 On 03.09.2016 22:15, Donald Eastlake wrote: >> - the difference between the "VLAN Block Case" (2.1) and "Extensible >> Case" (2.2) feels artificial. Why not add a "VLAN block TLV", which >> contains the list of VLAN start/end fields? > > As I recall this was in order to make the VLAN Block case closer to, > for convenience, an existing implemented address flush RBridge channel > message (using one of the "Private Use" RBridge Channel message > protocol numbers) that only applies to VLAN blocks. Okay, I didn't check for similarity with older messages. > I'll see what people think about merging the cases. One more question, is case 2.2 optional to implement or is it mandatory? >> - maybe the Nicknames could also be moved into a TLV, allowing to >> process the whole message with a single TLV based parser. > > I can see making a common TLV format for all the non-nickname lists > but I'm not sure there is much advantage to doing so for nicknames. Unified parser codepath... maybe even with checking the TLVs against=20 some kind of "schema" before processing them. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Zanderstrasse 5, 53177 Bonn, Germany Telefon +49 228 50212-469 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de From nobody Wed Sep 7 13:41:21 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0CD12B213 for ; Wed, 7 Sep 2016 13:41:19 -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=venaas-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tMjXZmtxJcY for ; Wed, 7 Sep 2016 13:41:17 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 4A9C312B2BB for ; Wed, 7 Sep 2016 13:41:17 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id g62so6937705lfe.3 for ; Wed, 07 Sep 2016 13:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=eo+7P5SumJnQtShPKG3lcDTb9tF5fiV3TYEraqv6oow=; b=Q+w6TPEs97J9hdLEwSndr0SuqO8vvizxohw6zqHh21bZUBjVGznmNJXOy6+iVyNknk fIDVvzUyEViN4oKWrfcglMsQpB5ReZkUOFUYhad1rB8YICH304R9GA3fDkQobjkOcRif pCwVTmj8crCAy2pPHbkJEmIVtGp7BESAPRBkzMtJSe3THk8UMpZJ+ck0i1L8CU7TbO7E O3y2OdTUcklaw34EyJ42/6lDiX7qaZdkzFBLC8e31xRVEcL4ngvACf/8vIrbGZYenXt0 KOsnK99Z6/sEYpUkDmJFfXtoJvpXGhq/aIfVfADuZzAreOEZ8bkB3RGve1tgBq0K5bvg kTEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=eo+7P5SumJnQtShPKG3lcDTb9tF5fiV3TYEraqv6oow=; b=nBnQbxSJ3xdzOYzzfuQf/BkOoPs6m8BJqyuBzeBK1hSBsWnf6jf5PxHZudKWJVwqLB 2RKOWw49RztSyehlIVEHMfjTGm2XAmGQWKGHe1SSYX/6ZI+LiXGQkC5zJhM8st75Y54I c6B/aiflDK5uEYpFCkR/jqiufpqDmKVIaHDExvCz0vDGeEYnH2OXZuc5IOXQaBTKlwkm 5ZetAjdn/6GZ8FDJPigDL3jT5HMIYYCaB9Tyg+TlsTAwqan1r3P3NYer0nvfVBm35NNe y2rU0NbBqPrwapvGaAPKwZteIfh1/7xbDGg8KiIftPVXxGVNtIjNdIVl8+T6ONZ8z7TO iKow== X-Gm-Message-State: AE9vXwMYx1zb0bN/d2zAKEHJSRhdbjo3WJmRJlA447OYvkxOHxTgZeLiDyBymnovlxaD7B2ayNdXT9B7OWBpVg== X-Received: by 10.25.44.142 with SMTP id s136mr430206lfs.156.1473280875129; Wed, 07 Sep 2016 13:41:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.15 with HTTP; Wed, 7 Sep 2016 13:41:14 -0700 (PDT) From: Stig Venaas Date: Wed, 7 Sep 2016 13:41:14 -0700 Message-ID: To: rtg-ads@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 20:41:20 -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-lisp-lcaf-14.txt Reviewer: Stig Venaas Review Date: 2016-09-07 IETF LC End Date: Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resolved before publication. The draft is almost ready but there are several places where the text is a bit unclear, and where there could be potential interoperability issues if people get it wrong. Here are the issues I found in the order they appear in the document. They are all mostly minor issues, but a few of them are just nits. In section 1 I find this sentence a bit misleading since [AFI] doesn't talk about the formatting. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: Is the formatting shown here for AFI 1 and 2 defined in another document? It would be good to have a reference. If it is introduced in this document, then it should not be in the introduction. In section 2, first paragraph it says: There is an address family currently defined for IPv4 or IPv6 addresses. It would be better to say that address families are defined for IPv4 and IPv6 addresses. In section 3 we have this paragraph: The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification. I'm not sure what conventional experience means. Please try to find a better way to say it. Regarding the last sentence, what if a you want to define new LCAF encodings in the future? Is it good to say that this specification takes precedent over any other? In section 3 we have this paragraph: Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. Can you phrase this differently? First it says that any LCAF encoded address has a minimum length of 8, but then it goes on to say how it sometimes is only 6. I understand what you're trying to say, but there may be a better way of stating it. In section 3 it says: Rsvd2: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Some of the LCAFs specified in this document are using it though. Hence you may need to change this text, and maybe not make it reserved. The last sentence of section 3 is: Therefore, when a locator-set has a mix of AFI records and LCAF records, all LCAF records will appear after all the AFI records. This is not necessarily true. Isn't it possible that one at some point in the future might use other AFI records that have AFI > 16387? IANA has assigned several values beyond 16387. In 4.1 it says: AFI = x: x can be any AFI value from [AFI]. Is 16387 always or sometimes allowed? Might be good to clarify that. This also applies to all the other LCAF types with similar language. Section 4.4: RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Tunnel Router (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of NTRs encoded is determined by the LCAF length field. When there are no NTRs supplied, the NTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero NTRs encoded. It is not quite clear to me if the NTR fields here are the RTR RLOC addresses. Does no NTR fields mean that there are no RTR RLOC addresses? If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length 0), and that would have AFI 0? Section 4.5 first paragraph: Multicast group information can be published in the mapping database. So a lookup on an group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. Can you have a mix of group addresses and unicast addresses? It's also not so clear from the format what source prefixes are. Are the source prefixes the same as the unicast RLOCs mentioned above? Can you have both multiple source addresses and then multiple group addresses? Can they be in arbitrarty order, or all sources followed by all groups? It seems one will need to inspect the address itself to tell whether it is a unicast or multicast address. This is probably fine. Section 4.6 Add description of Rsvd3. Section 4.7 Add description of Rsvd3 and Rsvd4. Section 4.10 In this section there are several examples of using the AFI List Type, but I miss a general definition. It appears that there can be a variable number of AFIs in the list. Any number > 0? It might be useful to have a length field associated with each AFI, or is it OK that parsing fails if an AFI is unknown, so that the address length is not known? Section 4.10.3 Isn't it unusual to include the 0 termination? Since you know the length it is not really needed. When parsing one will need to check the length either way, what should one do it the string accidentally is not 0-terminated? Section 4.10.4 I'm assuming that the recursion is more generic than this example? It might be worth trying to explain the more generic concept and format, and make sure that this is described as just an example. Section 4.10.5 This also appears to be just an example. Section 5.2 Key Field Num: the number of fields (minus 1) the key can be broken up into. The width of the fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 bytes in length. Allowing for a reasonable number of 16 field separators, valid values range from 0 to 15. It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates 5 fields? Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, right-justified in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and What does right-justified mean? Does it mean that the first field is the "low order" one? Basically at the end of the message? And the highest order bit corresponds to the part of the key right after the wilcards? I think this need to be explained better to ensure interoperability. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (shown above) minus 3. Isn't it exactly the value n, since the length is n + 3? Section 5.4 Length value n: length in bytes of fields that follow. This is a bit confusing. I think 2+n is the length in bytes that follow the lenght field. While n is the number of bytes after the JSON length. Section 5.5 It says "AFI = x" twice in the diagram. Based on this and the way it is described it might seem that the two AFI values must be the same value x, but they can differ, right? I this applies to several other messages types as well. Section 7 It looks like the table in the IANA considerations doesn't include all the types defined in this document. I'm happy to discuss my comments if needed, and also review any updates to this draft. Stig From nobody Wed Sep 7 14:12:18 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECCC12B1B9; Wed, 7 Sep 2016 14:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 DT26-9hvpxq0; Wed, 7 Sep 2016 14:12:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 DB80212B118; Wed, 7 Sep 2016 14:12:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BFE8D1C003B; Wed, 7 Sep 2016 14:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1473282731; bh=JVQ7F2rjNsS5R1m9V9MAH2DS3pPWw6vh5N6hEFqpMLA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Jdc2tiVCnT22YRkdjHlRveNIRr7B3pEqeF41NSLMrNKYFgiQ3ObD6remvdOt8gVVn 8FRFlWJAIDJARCFfNqVicmANk5HizlGnKxFO6tmMDD8s1pgc3MppnMt7XZt6lYn+DM 5euEOI3ikIWAKJoWe/A+j/ew9WV5LJDh2fb4YJDY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D75CDD80038; Wed, 7 Sep 2016 14:12:10 -0700 (PDT) To: Stig Venaas , rtg-ads@ietf.org References: From: "Joel M. Halpern" Message-ID: <23099e24-4575-5231-84b9-8a5a6f6ab2be@joelhalpern.com> Date: Wed, 7 Sep 2016 17:14:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 21:12:14 -0000 Thanks Stig. This looks very useful. Authors, can you please respond? Yours, Joel On 9/7/16 4:41 PM, Stig Venaas 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-lisp-lcaf-14.txt > Reviewer: Stig Venaas > Review Date: 2016-09-07 > IETF LC End Date: > Intended Status: Experimental > > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. > > The draft is almost ready but there are several places where the text > is a bit unclear, > and where there could be potential interoperability issues if people > get it wrong. Here > are the issues I found in the order they appear in the document. They > are all mostly > minor issues, but a few of them are just nits. > > In section 1 I find this sentence a bit misleading since [AFI] doesn't > talk about the formatting. > > Currently defined AFIs include IPv4 and IPv6 addresses, which are > formatted according to code-points assigned in [AFI] as follows: > > Is the formatting shown here for AFI 1 and 2 defined in another > document? It would be good to have a reference. If it is introduced > in this document, then it should not be in the introduction. > > In section 2, first paragraph it says: > There is an address family currently defined for IPv4 or IPv6 > addresses. > > It would be better to say that address families are defined for IPv4 > and IPv6 addresses. > > In section 3 we have this paragraph: > > The Address Family AFI definitions from [AFI] only allocate code- > points for the AFI value itself. The length of the address or entity > that follows is not defined and is implied based on conventional > experience. Where the LISP protocol uses LISP Canonical Addresses > specifically, the address length definitions will be in this > specification and take precedent over any other specification. > > I'm not sure what conventional experience means. Please try to find a > better way to say it. Regarding the last sentence, what if a you want > to define new LCAF encodings in the future? Is it good to say that this > specification takes precedent over any other? > > In section 3 we have this paragraph: > > Length: this 16-bit field is in units of bytes and covers all of the > LISP Canonical Address payload, starting and including the byte > after the Length field. So any LCAF encoded address will have a > minimum length of 8 bytes when the Length field is 0. The 8 bytes > include the AFI, Flags, Type, Reserved, and Length fields. When > the AFI is not next to encoded address in a control message, then > the encoded address will have a minimum length of 6 bytes when the > Length field is 0. The 6 bytes include the Flags, Type, Reserved, > and Length fields. > > Can you phrase this differently? First it says that any LCAF encoded > address has a minimum length of 8, but then it goes on to say how it > sometimes is only 6. I understand what you're trying to say, but there > may be a better way of stating it. > > In section 3 it says: > > Rsvd2: this 8-bit field is reserved for future use and MUST be > transmitted as 0 and ignored on receipt. > > Some of the LCAFs specified in this document are using it though. Hence > you may need to change this text, and maybe not make it reserved. > > The last sentence of section 3 is: > > Therefore, when a locator-set has a mix of AFI records and > LCAF records, all LCAF records will appear after all the AFI records. > > This is not necessarily true. Isn't it possible that one at some point > in the future might use other AFI records that have AFI > 16387? IANA > has assigned several values beyond 16387. > > In 4.1 it says: > AFI = x: x can be any AFI value from [AFI]. > > Is 16387 always or sometimes allowed? Might be good to clarify that. > This also applies > to all the other LCAF types with similar language. > > Section 4.4: > > RTR RLOC Address: this is an encapsulation address used by an ITR or > PITR which resides behind a NAT device. This address is known to > have state in a NAT device so packets can flow from it to the LISP > ETR behind the NAT. There can be one or more NAT Tunnel Router > (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these > set of fields. The number of NTRs encoded is determined by the > LCAF length field. When there are no NTRs supplied, the NTR > fields can be omitted and reflected by the LCAF length field or an > AFI of 0 can be used to indicate zero NTRs encoded. > > It is not quite clear to me if the NTR fields here are the RTR RLOC > addresses. Does no NTR fields mean that there are no RTR RLOC addresses? > If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length > 0), and that would have AFI 0? > > Section 4.5 first paragraph: > > Multicast group information can be published in the mapping database. > So a lookup on an group address EID can return a replication list of > RLOC group addresses or RLOC unicast addresses. > > Can you have a mix of group addresses and unicast addresses? It's also > not so clear from the format what source prefixes are. Are the source > prefixes the same as the unicast RLOCs mentioned above? Can you have > both multiple source addresses and then multiple group addresses? Can > they be in arbitrarty order, or all sources followed by all groups? > It seems one will need to inspect the address itself to tell whether it > is a unicast or multicast address. This is probably fine. > > Section 4.6 > Add description of Rsvd3. > > Section 4.7 > Add description of Rsvd3 and Rsvd4. > > Section 4.10 > In this section there are several examples of using the AFI List Type, > but I miss a general definition. It appears that there can be a variable > number of AFIs in the list. Any number > 0? It might be useful to have > a length field associated with each AFI, or is it OK that parsing fails if > an AFI is unknown, so that the address length is not known? > > Section 4.10.3 > Isn't it unusual to include the 0 termination? Since you know the > length it is not really needed. When parsing one will need to check > the length either way, what should one do it the string accidentally > is not 0-terminated? > > Section 4.10.4 > I'm assuming that the recursion is more generic than this example? > It might be worth trying to explain the more generic concept and > format, and make sure that this is described as just an example. > > Section 4.10.5 > This also appears to be just an example. > > Section 5.2 > Key Field Num: the number of fields (minus 1) the key can be broken > up into. The width of the fields are fixed length. So for a key > size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 > bytes in length. Allowing for a reasonable number of 16 field > separators, valid values range from 0 to 15. > > It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates > 5 fields? > > Key Wildcard Fields: describes which fields in the key are not used > as part of the key lookup. This wildcard encoding is a bitfield. > Each bit is a don't-care bit for a corresponding field in the key. > Bit 0 (the low-order bit) in this bitfield corresponds the first > field, right-justified in the key, bit 1 the second field, and so > on. When a bit is set in the bitfield it is a don't-care bit and > > What does right-justified mean? Does it mean that the first field is the > "low order" one? Basically at the end of the message? And the highest > order bit corresponds to the part of the key right after the wilcards? > I think this need to be explained better to ensure interoperability. > > Key: the variable length key used to do a LISP Database Mapping > lookup. The length of the key is the value n (shown above) minus > 3. > > Isn't it exactly the value n, since the length is n + 3? > > Section 5.4 > Length value n: length in bytes of fields that follow. > This is a bit confusing. I think 2+n is the length in bytes that follow > the lenght field. While n is the number of bytes after the JSON length. > > Section 5.5 > > It says "AFI = x" twice in the diagram. Based on this and the way it > is described it might seem that the two AFI values must be the same > value x, but they can differ, right? I this applies to several other > messages types as well. > > Section 7 > It looks like the table in the IANA considerations doesn't include all > the types defined in this document. > > I'm happy to discuss my comments if needed, and also review any > updates to this draft. > > Stig > From nobody Wed Sep 7 14:31:52 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1B12B2EC; Wed, 7 Sep 2016 14:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQJjfQ_iOGmP; Wed, 7 Sep 2016 14:31:47 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 2CE3512B278; Wed, 7 Sep 2016 14:31:47 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id g202so10480087pfb.0; Wed, 07 Sep 2016 14:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jQBS1D6QUFiXKy9GJwzoGCD0JK3poDou0JoJ1B2a9Hc=; b=N8AcS6FWUxNscJi5TSkRbawZ59Zfl20owT0hDBMpqRNM4zyPpE0ZfAtjZfjD7mmH6L GxBL0g6z4bvUmb/hSWoFNbjJVSdZ4b2s3IwdICS7UiA1+foUPS0Xa/cI1fOEAs6BcsnW qAzx1YxRO4gFYMvhoYCuT/st+zqZf3vdciszWf/+6ZTT1DIXZ7P2hzCEBVDSoxrHcaEg KStE7kkiSYnC/BJ7diLdyQ5XM7AGW5xIwYN0rkz9lHiQQoYpxg2J6++f2VkNmhlc3Dxu 6d9V977wXENGAkMthBNjH2OiH8BUMK5vgx0lGgwaFlhbaD4klAWcvSjrXO0Gtoz2o2gb 5Qmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jQBS1D6QUFiXKy9GJwzoGCD0JK3poDou0JoJ1B2a9Hc=; b=ieQHlKcwUs9jXBbvYKYKZ8MoY8UL4bPA330e4VENizLEaT5B+sdk+Wg+xSX9LYE1tQ LMp+lNxyMRt95YBgifu0WPSYMKku3LB+LANXEly43t9+GVz7UtGgrO0VyC3zT0R8/z+Z aagRQxF475IDaytv+XTgb7nOB5gqozDzNTzS3fmQtEnUJ6qcqNfv0QVOKaEl+xzuuzsh HJM65pTOZTzyiux/bfRHUUsRoG0vII2ehnlRClrdUi1ZdnoD50YMRH77HVunz5GBQ3jO QO74xoweSXuZgteFWzbg57Tgweby13otvqspETtNGoIXT2+1GXqt52sLkqN9p1Yd9SNf /0Mw== X-Gm-Message-State: AE9vXwPWKQfaRkuXiUPiHsi+yk4fwnjjg9kP4l9MYMQ/LdEscFiru9aiv8q5hrmAta3iLQ== X-Received: by 10.98.71.150 with SMTP id p22mr34409153pfi.156.1473283906619; Wed, 07 Sep 2016 14:31:46 -0700 (PDT) Received: from [13.7.28.189] ([13.7.28.189]) by smtp.gmail.com with ESMTPSA id h66sm27936649pfc.47.2016.09.07.14.31.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Sep 2016 14:31:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: <23099e24-4575-5231-84b9-8a5a6f6ab2be@joelhalpern.com> Date: Wed, 7 Sep 2016 14:31:44 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6AF00186-F8C4-4169-9960-BF3EF572D0D4@gmail.com> References: <23099e24-4575-5231-84b9-8a5a6f6ab2be@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, Stig Venaas , LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org, rtg-dir@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 21:31:50 -0000 I will try to respond tomorrow. Thanks for your comments Stig. Dino > On Sep 7, 2016, at 2:14 PM, Joel M. Halpern wrote: > > Thanks Stig. This looks very useful. > > Authors, can you please respond? > Yours, > Joel > > On 9/7/16 4:41 PM, Stig Venaas 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-lisp-lcaf-14.txt >> Reviewer: Stig Venaas >> Review Date: 2016-09-07 >> IETF LC End Date: >> Intended Status: Experimental >> >> Summary: >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> The draft is almost ready but there are several places where the text >> is a bit unclear, >> and where there could be potential interoperability issues if people >> get it wrong. Here >> are the issues I found in the order they appear in the document. They >> are all mostly >> minor issues, but a few of them are just nits. >> >> In section 1 I find this sentence a bit misleading since [AFI] doesn't >> talk about the formatting. >> >> Currently defined AFIs include IPv4 and IPv6 addresses, which are >> formatted according to code-points assigned in [AFI] as follows: >> >> Is the formatting shown here for AFI 1 and 2 defined in another >> document? It would be good to have a reference. If it is introduced >> in this document, then it should not be in the introduction. >> >> In section 2, first paragraph it says: >> There is an address family currently defined for IPv4 or IPv6 >> addresses. >> >> It would be better to say that address families are defined for IPv4 >> and IPv6 addresses. >> >> In section 3 we have this paragraph: >> >> The Address Family AFI definitions from [AFI] only allocate code- >> points for the AFI value itself. The length of the address or entity >> that follows is not defined and is implied based on conventional >> experience. Where the LISP protocol uses LISP Canonical Addresses >> specifically, the address length definitions will be in this >> specification and take precedent over any other specification. >> >> I'm not sure what conventional experience means. Please try to find a >> better way to say it. Regarding the last sentence, what if a you want >> to define new LCAF encodings in the future? Is it good to say that this >> specification takes precedent over any other? >> >> In section 3 we have this paragraph: >> >> Length: this 16-bit field is in units of bytes and covers all of the >> LISP Canonical Address payload, starting and including the byte >> after the Length field. So any LCAF encoded address will have a >> minimum length of 8 bytes when the Length field is 0. The 8 bytes >> include the AFI, Flags, Type, Reserved, and Length fields. When >> the AFI is not next to encoded address in a control message, then >> the encoded address will have a minimum length of 6 bytes when the >> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >> and Length fields. >> >> Can you phrase this differently? First it says that any LCAF encoded >> address has a minimum length of 8, but then it goes on to say how it >> sometimes is only 6. I understand what you're trying to say, but there >> may be a better way of stating it. >> >> In section 3 it says: >> >> Rsvd2: this 8-bit field is reserved for future use and MUST be >> transmitted as 0 and ignored on receipt. >> >> Some of the LCAFs specified in this document are using it though. Hence >> you may need to change this text, and maybe not make it reserved. >> >> The last sentence of section 3 is: >> >> Therefore, when a locator-set has a mix of AFI records and >> LCAF records, all LCAF records will appear after all the AFI records. >> >> This is not necessarily true. Isn't it possible that one at some point >> in the future might use other AFI records that have AFI > 16387? IANA >> has assigned several values beyond 16387. >> >> In 4.1 it says: >> AFI = x: x can be any AFI value from [AFI]. >> >> Is 16387 always or sometimes allowed? Might be good to clarify that. >> This also applies >> to all the other LCAF types with similar language. >> >> Section 4.4: >> >> RTR RLOC Address: this is an encapsulation address used by an ITR or >> PITR which resides behind a NAT device. This address is known to >> have state in a NAT device so packets can flow from it to the LISP >> ETR behind the NAT. There can be one or more NAT Tunnel Router >> (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these >> set of fields. The number of NTRs encoded is determined by the >> LCAF length field. When there are no NTRs supplied, the NTR >> fields can be omitted and reflected by the LCAF length field or an >> AFI of 0 can be used to indicate zero NTRs encoded. >> >> It is not quite clear to me if the NTR fields here are the RTR RLOC >> addresses. Does no NTR fields mean that there are no RTR RLOC addresses? >> If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length >> 0), and that would have AFI 0? >> >> Section 4.5 first paragraph: >> >> Multicast group information can be published in the mapping database. >> So a lookup on an group address EID can return a replication list of >> RLOC group addresses or RLOC unicast addresses. >> >> Can you have a mix of group addresses and unicast addresses? It's also >> not so clear from the format what source prefixes are. Are the source >> prefixes the same as the unicast RLOCs mentioned above? Can you have >> both multiple source addresses and then multiple group addresses? Can >> they be in arbitrarty order, or all sources followed by all groups? >> It seems one will need to inspect the address itself to tell whether it >> is a unicast or multicast address. This is probably fine. >> >> Section 4.6 >> Add description of Rsvd3. >> >> Section 4.7 >> Add description of Rsvd3 and Rsvd4. >> >> Section 4.10 >> In this section there are several examples of using the AFI List Type, >> but I miss a general definition. It appears that there can be a variable >> number of AFIs in the list. Any number > 0? It might be useful to have >> a length field associated with each AFI, or is it OK that parsing fails if >> an AFI is unknown, so that the address length is not known? >> >> Section 4.10.3 >> Isn't it unusual to include the 0 termination? Since you know the >> length it is not really needed. When parsing one will need to check >> the length either way, what should one do it the string accidentally >> is not 0-terminated? >> >> Section 4.10.4 >> I'm assuming that the recursion is more generic than this example? >> It might be worth trying to explain the more generic concept and >> format, and make sure that this is described as just an example. >> >> Section 4.10.5 >> This also appears to be just an example. >> >> Section 5.2 >> Key Field Num: the number of fields (minus 1) the key can be broken >> up into. The width of the fields are fixed length. So for a key >> size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 >> bytes in length. Allowing for a reasonable number of 16 field >> separators, valid values range from 0 to 15. >> >> It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates >> 5 fields? >> >> Key Wildcard Fields: describes which fields in the key are not used >> as part of the key lookup. This wildcard encoding is a bitfield. >> Each bit is a don't-care bit for a corresponding field in the key. >> Bit 0 (the low-order bit) in this bitfield corresponds the first >> field, right-justified in the key, bit 1 the second field, and so >> on. When a bit is set in the bitfield it is a don't-care bit and >> >> What does right-justified mean? Does it mean that the first field is the >> "low order" one? Basically at the end of the message? And the highest >> order bit corresponds to the part of the key right after the wilcards? >> I think this need to be explained better to ensure interoperability. >> >> Key: the variable length key used to do a LISP Database Mapping >> lookup. The length of the key is the value n (shown above) minus >> 3. >> >> Isn't it exactly the value n, since the length is n + 3? >> >> Section 5.4 >> Length value n: length in bytes of fields that follow. >> This is a bit confusing. I think 2+n is the length in bytes that follow >> the lenght field. While n is the number of bytes after the JSON length. >> >> Section 5.5 >> >> It says "AFI = x" twice in the diagram. Based on this and the way it >> is described it might seem that the two AFI values must be the same >> value x, but they can differ, right? I this applies to several other >> messages types as well. >> >> Section 7 >> It looks like the table in the IANA considerations doesn't include all >> the types defined in this document. >> >> I'm happy to discuss my comments if needed, and also review any >> updates to this draft. >> >> Stig >> From nobody Thu Sep 8 06:21:26 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208F712B364; Thu, 8 Sep 2016 06:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 YyfxJtl7tP_4; Thu, 8 Sep 2016 06:21:20 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 A385412B52D; Thu, 8 Sep 2016 05:57:45 -0700 (PDT) X-AuditID: c6180641-2580a98000000a0b-4e-57d10be5b297 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 5B.07.02571.5EB01D75; Thu, 8 Sep 2016 08:57:42 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0301.000; Thu, 8 Sep 2016 08:57:42 -0400 From: Eric Gray To: Jiazi YI , "draft-ietf-manet-smf-sec-threats@tools.ietf.org" Thread-Topic: [manet] RTG-Dir Review of draft-ietf-manet-smf-sec-threats-05 Thread-Index: AdHxrwmJaguaDdoGQriqrxN4uU7wsgOXdA0AAnDijzA= Date: Thu, 8 Sep 2016 12:57:42 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64A8ADBF9@eusaamb107.ericsson.se> References: <48E1A67CB9CA044EADFEAB87D814BFF64A871DE8@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF64A8ADBF9eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyuXRPoO4z7ovhBktuClm8OnaKxWLDMmaL f1uesFucnPOD2WLBmqfsDqweS5b8ZPLYNnUJo8eXy5/ZApijuGxSUnMyy1KL9O0SuDKalvez FDw7wlSx6foflgbGFXuYuhg5OCQETCRWb2fsYuTiEBLYwCjxc+49dghnGaPEvm3TgDKcHGwC GhLH7qwFqxIR6GCU+H5rBxNIglmgVOL7mz3sILawgJfE4d+nmUFsEQFvif75v1ggbCuJu1c6 weIsAioSTyc9YAOxeQV8JZaubmSC2DaFUWLtj6VgDZwCgRLXj/8EsxkFxCS+n1oDtUxc4taT +WC2hICAxJI955khbFGJl4//sULYShKTlp5jhajPlzhx/hnUMkGJkzOfsExgFJmFZNQsJGWz kJTNAoYMs4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FyFFaXJCTm25kuIkRGGnHJNgc dzDu7fU8xCjAwajEw6vw9Hy4EGtiWXFl7iFGCQ5mJRFe9/iL4UK8KYmVValF+fFFpTmpxYcY pTlYlMR59V8qhgsJpCeWpGanphakFsFkmTg4pRoY9WSuxdx5XOZ2ctrHb3IFDco+K34XFjMd u33t+cSwf8krgryWnspktVFZ7K60WfIxj3Tr42PFcya+26Ol0d1mLn/p5Ospv7//W3JgjVHl zEN8hczlPw4svVN68cfCFbX9+SUy5hqBVWJZSov7z4YwZK7tlbQv9jVmcIxPElKel6LAr3n2 S46EEktxRqKhFnNRcSIATecyILACAAA= Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "manet@ietf.org" Subject: Re: [RTG-DIR] [manet] RTG-Dir Review of draft-ietf-manet-smf-sec-threats-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 13:21:25 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF64A8ADBF9eusaamb107erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmlhemksDQoNCiAgICAgICAgICAgICAgICBJIGhhdmUgcmUtcmV2aWV3ZWQgdGhlIGxhdGVzdCBk cmFmdCBhbmQgYmVsaWV2ZSB0aGF0IGFsbCBvZiBteSBlYXJsaWVyIGNvbW1lbnRzIGhhdmUgYmVl biBhZGRyZXNzZWQuDQoNCiAgICAgICAgICAgICAgICBUaGFua3MhDQotLQ0KRXJpYw0KDQpGcm9t OiB5aS5qaWF6aUBnbWFpbC5jb20gW21haWx0bzp5aS5qaWF6aUBnbWFpbC5jb21dIE9uIEJlaGFs ZiBPZiBKaWF6aSBZSQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjYsIDIwMTYgNjo0NCBQTQ0KVG86 IEVyaWMgR3JheSA8ZXJpYy5ncmF5QGVyaWNzc29uLmNvbT4NCkNjOiBkcmFmdC1pZXRmLW1hbmV0 LXNtZi1zZWMtdGhyZWF0c0B0b29scy5pZXRmLm9yZzsgcnRnLWFkc0BpZXRmLm9yZzsgcnRnLWRp ckBpZXRmLm9yZzsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJURy1EaXIg UmV2aWV3IG9mIGRyYWZ0LWlldGYtbWFuZXQtc21mLXNlYy10aHJlYXRzLTA1DQpJbXBvcnRhbmNl OiBIaWdoDQoNCkRlYXIgRXJpYywgYWxsOg0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJl dmlldyBhbmQgY29tbWVudHMuIFdlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IHJldmlzaW9uIGJhc2Vk IG9uIHRoZSBjb21tZW50cyByZWNlaXZlZC4NCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW1hbmV0LXNtZi1zZWMtdGhyZWF0cy8NClRoZXJlJ3MgYWxzbyBhIGh0bWxp emVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtbWFuZXQtc21mLXNlYy10aHJlYXRzLTA2DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1tYW5ldC1zbWYtc2VjLXRocmVhdHMtMDYNCg0KDQpQbGVhc2UgZmlu ZCB0aGUgcmVwbHkgaW5saW5lOg0KDQpPbiBUdWUsIEF1ZyA5LCAyMDE2IGF0IDk6MjYgUE0sIEVy aWMgR3JheSA8ZXJpYy5ncmF5QGVyaWNzc29uLmNvbTxtYWlsdG86ZXJpYy5ncmF5QGVyaWNzc29u LmNvbT4+IHdyb3RlOg0KDQo8c25pcD4NCg0KDQpNYWpvciBJc3N1ZXM6DQpObyBtYWpvciBpc3N1 ZXMgZm91bmQuDQoNCk1pbm9yIElzc3VlczoNClJGQyA2NjIxIGRpc2N1c3NlcyBhIGZldyBzZWN1 cml0eSBpc3N1ZXMgd2hpY2ggZG8gbm90IGxvb2sgdG8gaGF2ZSBiZWVuIHJlZmVyZW5jZWQgaW4g dGhpcyBkcmFmdCwgZXZlbiBpbmRpcmVjdGx5LiAgVGhlcmUgYXJlIGdvb2QgcmVhc29ucyB3aHkg dGhpcyBpcyB1bnVzdWFsLg0KDQpNb3JlIGV4cGxpY2l0IHJlZmVyZW5jZXMgdG8gdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBvZiBSRkM2NjIxIGFyZSBhZGRlZCBib3RoIGluIHRo ZSBpbnRyb2R1Y3Rpb24gYW5kIHJlbGF0ZWQgc2VjdGlvbnMuDQoNClNpbWlsYXJseSwgd2hpbGUg dGhlIGRyYWZ0IGRvZXMgbWFrZSBhdCBsZWFzdCBhbiBvYmxpcXVlIHJlZmVyZW5jZSB0byB0aGUg c2VjdXJpdHkgaXNzdWVzIHRoYXQgYXBwbHkgdG8gUkZDIDYxMzAsIGl0IGlzIG5vdCBjbGVhciB3 aXRob3V0IGV4dGVuc2l2ZSByZWFkaW5nIHdoYXQgdGhpcyBkcmFmdCBhZGRyZXNzZXMgdGhhdCBp cyBub3QgKGF0IGxlYXN0IHN1ZmZpY2llbnRseSkgYWRkcmVzc2VkIHRoZXJlIChvciBpbiBSRkMg NzE4NikuDQoNClRvd2FyZCB0aGUgZW5kIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gc2VjdGlv biAzIChTTUYgVGhyZWF0cyBPdmVydmlldyksIHRoZSBkcmFmdCBtYWtlcyBhbiBhc3NlcnRpb24g dGhhdCBpcyBub3QgY29uc2lzdGVudCB3aXRoIG90aGVyIHRleHQgaW4gdGhlIHNhbWUgcGFyYWdy YXBoOyBpdCBjbGFpbXMgdGhhdCDigJxTTUYgcmVsaWVzIG9uIE5IRFDigJ0gd2hpbGUgb3RoZXIg dGV4dCwgaW5jbHVkaW5nIHRleHQgaW4gdGhlIHNhbWUgcGFyYWdyYXBoLCBzZWVtcyBzdHJvbmds eSB0byBpbmRpY2F0ZSB0aGF0IE5IRFAgaXMgb25lIGFsdGVybmF0aXZlIGFwcHJvYWNoIHRoYXQg bWlnaHQgYmUgdXNlZC4NCg0KTm90ZSB0aGF0IEkgd2FzIHVuYWJsZSB0byBwYXJzZSBwYXJ0IG9m IHRoaXMgc2FtZSBzZW50ZW5jZTogd2hhdCBkb2VzIOKAnChub3QgbWF0dGVyIGlmIG90aGVyIOKA piBmb3IgMS1ob3AgbmVpZ2hib3IgZGlzY292ZXJ5KeKAnSBtZWFuPw0KDQpTTUYgcmVxdWlyZXMg MS1ob3AgYW5kIDItaG9wIG5laWdoYm91cmhvb2QgaW5mb3JtYXRpb24gdG8gcmVkdWNlIHRoZSBy ZWxheSBzZXQuIFNNRiBhbGxvd3MgYWx0ZXJuYXRpdmUgbG93LWxheWVyIGluZm9ybWF0aW9uIHRv IHByb3ZpZGUgbmVjZXNzYXJ5IG5laWdoYm91cmhvb2QgaW5mb3JtYXRpb24gLS0gYnV0IHRoYXQn cyBvbmx5IGZvciAxLWhvcCBuZWlnaGJvdXJob29kLiBCdXQgZm9yIDItaG9wIG5laWdoYm91ciBp bmZvcm1hdGlvbiwgb25seSBOSERQIGlzIHVzZWQgaW4gU01GLg0KV2UgY2xhcmlmaWVkIHRoZSBk aWZmZXJlbmNlIGluIHRoZSBzZWN0aW9uLg0KDQoNClNlY3Rpb24gNC4xLjEgKFJlcGxheSBBdHRh Y2spIGFwcGVhcnMgdG8gYWRkcmVzcyBhbiBpc3N1ZSB0aGF0IGEpIGlzIG5vdCBuZWNlc3Nhcmls eSBhIGNvbnRyb2wgcGxhbmUgYXR0YWNrIChhcyBpbXBsaWVkIGluIHRoZSBmaXJzdCBwYXJhZ3Jh cGgpLA0KYW5kIGIpIGlzIGNsZWFybHkgYSB2YXJpYXRpb24gb2YgYSB0aHJlYXQgZGVzY3JpYmVk IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIFJGQyA2NjIxIGFzIGEg RG9TIGF0dGFjay4gIEJlY2F1c2UgdGhlIHNwZWNpZmljIHRocmVhdCBpbiBib3RoIGNhc2VzICh0 aGUgY2FzZSBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uIGFuZCB0aGF0IGRlc2NyaWJlZCBpbiBS RkMgNjYyMSkgaW52b2x2ZXMgdXNpbmcgc29tZSBtZWFucyBvZiBkZWxpdmVyaW5nIGJvZ3VzIHBh Y2tldHMgZWFybGllciB0aGFuIHN1YnNlcXVlbnQgbGVnaXRpbWF0ZSBwYWNrZXRzLCB0aGlzIGRv ZXMgbm90IChhdCBsZWFzdCBpbnR1aXRpdmVseSkgc2VlbSBsaWtlIGEgcmVwbGF5IGF0dGFjay4N Cg0KV2UgY2hhbmdlZCB0aGUgbmFtZSBvZiB0aGUgc2VjdGlvbiB0byBBdHRhY2sgdG8gSG9wIExp bWl0IHRvIGF2b2lkIGFtYmlndWl0eS4NCg0KDQpTZWN0aW9uIDQuMi4xIOKAkyBQcmUtYWN0aXZh dGlvbiBBdHRhY2tzIChQcmUtUGxheSkg4oCTIHNpbWlsYXJseSBhcHBlYXJzIHRvIGFkZHJlc3Mg b25lIHNwZWNpZmljIGV4YW1wbGUgb2YgYSBzZWNvbmQgZ2VuZXJhbCBjbGFzcyBvZiB0aHJlYXQg ZGVzY3JpYmVkIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIFJGQyA2 NjIxIChpc3N1ZXMgd2l0aCB1c2Ugb2YgcHJlZGljdGFibGUgc2VxdWVuY2luZyB0ZWNobmlxdWVz KS4NCg0KVGhlIHNhbWUgYXBwbGllcyB0byBzZWN0aW9uIDQuMi4yIOKAkyBEZS1hY3RpdmF0aW9u IGF0dGFja3MuDQoNCkl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB0aGUgbGVhZGluZyB0ZXh0IGluIHNl Y3Rpb24gNC4yIHRhbGtlZCBnZW5lcmFsbHkgYWJvdXQgdGhlIHJlbGF0ZWQgYXR0YWNrIHZlY3Rv ciBkZXNjcmliZWQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgUkZD IDY2MjEgYW5kIHdoeSB0aGlzIGRyYWZ0IG5lZWRzIHRvIGV4cGFuZCBvbiB0aGlzIGNsYXNzIG9m IHRocmVhdCAoYXNzb2NpYXRlZCB3aXRoIEktRFBEKSBkZXNjcmliZWQgdGhlcmUuDQoNClNlY3Rp b24gNC4zIGFsc28gc2ltaWxhcmx5IHByb3ZpZGVzIGFuIGV4cGFuc2lvbiBvbiBhIGNsYXNzIG9m IHRocmVhdHMgKGFzc29jaWF0ZWQgd2l0aCBILURQRCkgYWxyZWFkeSBkZXNjcmliZWQgaW4gUkZD IDY2MjEuDQoNCkluIGdlbmVyYWwsIEkgZmVlbCB0aGF0IHRoZSBleHBhbnNpb25zIHByb3ZpZGVk IGluIHNlY3Rpb24gNCBvZiB0aGlzIGRyYWZ0IHByb3ZpZGUgdXNlZnVsIGluZm9ybWF0aW9uIOKA kyBhcyBleGFtcGxlcywgYXQgbGVhc3QuICBIb3dldmVyLCB0aGlzIHNlY3Rpb24gc2hvdWxkIGV4 cGxpY2l0bHkgcmVmZXIgdG8gYXBwbGljYWJsZSB0ZXh0IGluIFJGQyA2NjIxLCB3aGljaCBpbmNs dWRlcyBzdWdnZXN0aW9ucyBvbiB3YXlzIHRvIG1pdGlnYXRlIHRoZXNlIHRocmVhdHMuICBJZiB0 aGUgYXV0aG9ycyBhbmQvb3IgdGhlIHdvcmtpbmcgZ3JvdXAgZmVlbCB0aGF0IHRoZSBzdWdnZXN0 aW9ucyBtYWRlIGluIFJGQyA2NjIxIGFyZSBpbnN1ZmZpY2llbnQsIGl0IHdvdWxkIGJlIHVzZWZ1 bCB0byBzYXkgd2h5IHRoaXMgaXMgdGhlIGNhc2UgaW4gdGhpcyBkb2N1bWVudC4NCg0KV2UgYWRk ZWQgcmVmZXJlbmNlcyB0byByZWxhdGVkIHNlY3Rpb25zIGluIFJGQzY2MjEgYW5kIGV4cGxhaW5l ZCB3aHkgdGhvc2UgYXJlIGV4cGFuZGVkIGluIHRoaXMgZG9jdW1lbnQgYXQgdGhlIGJlZ2luIG9m IHNlY3Rpb24gNC4NCg0KDQpUaGUgc2VudGVuY2UgY29tcHJpc2luZyBzZWN0aW9uIDUuMSAoUmVs YXkgU2V0IFNlbGVjdGlvbiBDb21tb24gVGhyZWF0cykgZG9lcyBub3QgYXBwZWFyIHRvIGJlIGNv cnJlY3QgYXMgd3JpdHRlbjsgUkZDIDcxODYgZG9lcyBub3QgaW5jbHVkZSBhbnl0aGluZyBhYm91 dCBSU1MgYWxnb3JpdGhtcy4gIFRvIHRoZSBleHRlbnQgdGhhdCBSU1MgTUFZIGRlcGVuZCBvbiBO SERQLCBSRkMgNzE4NiBkb2VzIGRlc2NyaWJlIHRocmVhdHMgdG8gTkhEUCB0aGF0IHdvdWxkIGlt cGFjdCBSU1MgZm9yIHRoZXNlIGNhc2VzLiAgQXJndWFibHkgdGhlIHNhbWUgdGhyZWF0cyBtYXkg YXBwbHkgaW5kZXBlbmRlbnQgb2YgaG93IFNNRiByb3V0ZXJzIGJlY29tZSBhd2FyZSBvZiB0aGUg bmVpZ2hib3Job29kIHRvcG9sb2d5LCBidXQgdGhpcyBpcyBub3QgKGFuZCBwb3NzaWJseSBjYW5u b3QgYmUpIGtub3duIHdpdGhvdXQgZXhoYXVzdGl2ZSBhbmFseXNpcyBvZiBhbGwgbWV0aG9kcyBi eSB3aGljaCB0aGlzIGluZm9ybWF0aW9uIG1pZ2h0IGJlIGRldGVybWluZWQuDQoNClRoZSBSU1Mg aXMgYmFzZWQgb24gdGhlIG5laWdoYm91cmhvb2QgaW5mb3JtYXRpb24gb2J0YWluZWQgZnJvbSB0 aGUgY29udHJvbCBwbGFuZS4gRm9yIFNNRiwgYXMgZmFyIGFzIEkgY2FuIHNlZSwgb25seSBOSERQ IGlzIHVzZWQgaW4gcHJhY3RpY2UgdG8gb2J0YWluIG5laWdoYm91cmhvb2QgaW5mb3JtYXRpb24u IFNvIHRoZSBjb21tb24gdGhyZWF0cyBsaXN0ZWQgaW4gc2VjdGlvbiA1LjEgc3VjaCBhcyBEb1Ms IGVhdmVzZHJvcHBpbmcsIGV0Yy4gY2FuIGJlIGFwcGxpZWQgdG8gU01GIGRpcmVjdGx5IC0tIHRo YXQncyBhbHNvIG9uZSBvZiB0aGUgcHVycG9zZSBvZiBoYXZpbmcgUkZDNzE4NiBhcyBhbiBpbmRl cGVuZGVudCBkb2N1bWVudDogcmVsYXRlZCBjb250ZW50IGNhbiBiZSByZXVzZWQgYnkgcHJvdG9j b2xzIHN1Y2ggYXMgU01GIGFuZCBPTFNSdjIuDQoNCg0KDQpJbiBTZWN0aW9uIDUuMiAoVGhyZWF0 cyB0byBFLUNEUyBBbGdvcml0aG0pLCBSRkMgNTYxNCBpcyBnaXZlbiBhcyBhIHJlZmVyZW5jZSBm b3Ig4oCcRXNzZW50aWFsIENvbm5lY3RlZCBEb21pbmF0aW5nIFNldOKAnSAob3IgdGhlIEUtQ0RT IGFsZ29yaXRobSksIHdoZW4gUkZDIDU2MTQgYWN0dWFsbHkgZG9lcyBub3QgbWVudGlvbiBlaXRo ZXIgb25lIChpdCBkZWZpbmVzIENEUyBhbmQgdGFsa3MgYWJvdXQgYSBzbWFsbCBudW1iZXIgb2Yg YWxnb3JpdGhtcyDigJMgbm9uZSBvZiB3aGljaCBhcmUgZGlyZWN0bHkgcmVsYXRlZCB0byBFLUNE UzsgdGhlIHdvcmQg4oCcZXNzZW50aWFs4oCdIGRvZXMgbm90IGFwcGVhciB0byBiZSBpbmNsdWRl ZCBpbiB0aGUgUkZDIGFueXdoZXJlKS4gIEkgd2FzIG5vdCBhYmxlIHRvIGZpbmQgYSByZWZlcmVu Y2UgZm9yIHRoaXMgdGVybSBpbiBhIGZldyBtaW51dGVzIG9mIHBva2luZyBhcm91bmQsIHRob3Vn aCBpdCBpcyBlYXN5IGVub3VnaCB0byBmaW5kIHJlZmVyZW5jZXMgZm9yIOKAnG1pbmltdW0gY29u bmVjdGVkIGRvbWluYXRpbmcgc2V0LuKAnQ0KDQpJbiBSRkM2NjIxLCBSRkM1NjE0IGlzIGNpdGVk IHdoZW4gdGhlIEUtQ0RTIGlzIGludHJvZHVjZWQ6DQoNCiAgIFRoZSAiRXNzZW50aWFsIENvbm5l Y3RlZCBEb21pbmF0aW5nIFNldCIgKEUtQ0RTKSBhbGdvcml0aG0gW1JGQzU2MTRdDQogICBmb3Jt cyBhIHNpbmdsZSBDRFMgbWVzaCBmb3IgdGhlIFNNRiBvcGVyYXRpbmcgcmVnaW9uLg0KDQpBbHRo b3VnaCDigJxFc3NlbnRpYWwgQ29ubmVjdGVkIERvbWluYXRpbmcgU2V04oCdIGlzIG5vdCBleHBs aWNpdGx5IHVzZWQgaW4gUkZDNTYxNCwgYXMgYSBkZXJpdmF0aXZlLCBJIHRoaW5rIGl0J3Mgc3Rp bGwgYXBwcm9wcmlhdGUgKGFuZCBldmVuIG5lY2Vzc2FyeSkgdG8gY2l0ZSB0aGUgb3JpZ2luYWwg c291cmNlPw0KDQoNClRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIChzZWN0aW9u IDcpIG9mIHRoaXMgZHJhZnQgc2hvdWxkIHByb3ZpZGUgYSBzdW1tYXJ5IG9mIHNlY3VyaXR5IGlz c3VlcyBpbmNsdWRlZCBvciBhZGRyZXNzZWQgaW4gdGhpcyBkb2N1bWVudCAoZGlyZWN0bHkgb3Ig aW5kaXJlY3RseSBieSByZWZlcmVuY2UpIGFzIHdlbGwgYXMgYW55IHJlbGF0ZWQgc2VjdXJpdHkg aXNzdWVzIHlldCB0byBiZSBhZGRyZXNzZWQuIE1pbmltYWxseSwgaWYgdGhlIGF1dGhvcnMgZmVl bCB0aGF0IHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgaW4gc2VjdGlvbiAzIChTTUYgVGhy ZWF0cyBPdmVydmlldyksIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNob3Vs ZCBzYXkgdGhpcy4gIE9uZSBhcHByb2FjaCB3b3VsZCBiZSB0byB1c2UgdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIHNlY3Rpb24gdG8gc3VtbWFyaXplIHRoZSBtYWluIGNvbnRlbnQgb2YgdGhl IGRvY3VtZW50Lg0KDQpCeSB0YWtpbmcgY29uc2lkZXJhdGlvbiBvZiB0aGUgY29tbWVudHMgZnJv bSBBRCwgd2Ugc3VtbWFyaXNlZCB0aGUgY29udGVudCBvZiB0aGUgZG9jdW1lbnQgYW5kIG1lcmdl ZCB0aGUgImZ1dHVyZSB3b3JrIiBzZWN0aW9uIGluIHRoaXMgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgc2VjdGlvbi4NCg0KDQpOaXRzOg0KSSBoYWQgYSBudW1iZXIgb2YgaXNzdWVzIHdpdGgg4oCc ZXNvdGVyaWMgcXVlc3Rpb25zIG9mIEVuZ2xpc2ggdXNhZ2Uu4oCdIEhvd2V2ZXIsIGFjY29yZGlu ZyB0byBvdXIgaW5zdHJ1Y3Rpb25zLCDigJx0aGUgUkZDIEVkaXRvciB3aWxsIHNwb3QgdGhlc2Us IGFuZCBpdCBpcyBub3QgYSB3aXNlIHVzZSBvZiB0aW1lIHRvIGRpc2N1c3MgdGhlc2UgdGhpbmdz LuKAnQ0KDQoNClJGQyBlZGl0b3IgaXMgdGhlIGJlc3QgdGVhY2hlciB0byB0ZWxsIHVzIGhvdyB0 byB3cml0ZSBFbmdsaXNoIGNvcnJlY3RseSAtLSBlc3BlY2lhbGx5IGZvciBub24tbmF0aXZlIEVu Z2xpc2ggc3BlYWtlcnMgbGlrZSBtZSA6KQ0KDQpUaGFua3MgYWdhaW4gZm9yIHlvdXIgY29tbWVu dHMhIQ0KDQpyZWdhcmRzDQoNCkppYXppDQoNCuKYug0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGll dGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbWFuZXQNCg0K --_000_48E1A67CB9CA044EADFEAB87D814BFF64A8ADBF9eusaamb107erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SmlhemksDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGF2ZSByZS1yZXZpZXdlZCB0 aGUgbGF0ZXN0IGRyYWZ0IGFuZCBiZWxpZXZlIHRoYXQgYWxsIG9mIG15IGVhcmxpZXIgY29tbWVu dHMgaGF2ZSBiZWVuIGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FcmljPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB5aS5qaWF6aUBnbWFpbC5jb20gW21h aWx0bzp5aS5qaWF6aUBnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppYXppIFlJPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDI2LCAyMDE2IDY6NDQgUE08YnI+DQo8Yj5U bzo8L2I+IEVyaWMgR3JheSAmbHQ7ZXJpYy5ncmF5QGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IGRyYWZ0LWlldGYtbWFuZXQtc21mLXNlYy10aHJlYXRzQHRvb2xzLmlldGYub3JnOyBy dGctYWRzQGlldGYub3JnOyBydGctZGlyQGlldGYub3JnOyBtYW5ldEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBSVEctRGlyIFJldmlldyBvZiBkcmFmdC1pZXRmLW1h bmV0LXNtZi1zZWMtdGhyZWF0cy0wNTxicj4NCjxiPkltcG9ydGFuY2U6PC9iPiBIaWdoPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBFcmljLCBhbGw6Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgdmVyeSBt dWNoIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuIFdlIGp1c3Qgc3VibWl0dGVkIGEgbmV3 IHJldmlzaW9uIGJhc2VkIG9uIHRoZSBjb21tZW50cyByZWNlaXZlZC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1hbmV0LXNtZi1zZWMtdGhyZWF0cy8iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1zbWYtc2VjLXRocmVhdHMvPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KVGhlcmUncyBhbHNvIGEg aHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LXNtZi1zZWMtdGhyZWF0cy0w NiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1zbWYtc2VjLXRocmVhdHMtMDY8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQpBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1hbmV0LXNt Zi1zZWMtdGhyZWF0cy0wNiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tYW5l dC1zbWYtc2VjLXRocmVhdHMtMDY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgZmluZCB0aGUgcmVw bHkgaW5saW5lOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg QXVnIDksIDIwMTYgYXQgOToyNiBQTSwgRXJpYyBHcmF5ICZsdDs8YSBocmVmPSJtYWlsdG86ZXJp Yy5ncmF5QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVyaWMuZ3JheUBlcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7c25pcCZndDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+TWFqb3IgSXNzdWVzOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5vIG1ham9yIGlzc3VlcyBm b3VuZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1pbm9yIElzc3VlczoN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5SRkMgNjYyMSBkaXNjdXNzZXMgYSBmZXcgc2VjdXJpdHkgaXNzdWVz IHdoaWNoIGRvIG5vdCBsb29rIHRvIGhhdmUgYmVlbiByZWZlcmVuY2VkIGluIHRoaXMgZHJhZnQs IGV2ZW4gaW5kaXJlY3RseS4mbmJzcDsgVGhlcmUgYXJlIGdvb2QgcmVhc29ucyB3aHkgdGhpcyBp cw0KIHVudXN1YWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vcmUgZXhwbGljaXQgcmVm ZXJlbmNlcyB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIG9mIFJGQzY2MjEg YXJlIGFkZGVkIGJvdGggaW4gdGhlIGludHJvZHVjdGlvbiBhbmQgcmVsYXRlZCBzZWN0aW9ucy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2ltaWxh cmx5LCB3aGlsZSB0aGUgZHJhZnQgZG9lcyBtYWtlIGF0IGxlYXN0IGFuIG9ibGlxdWUgcmVmZXJl bmNlIHRvIHRoZSBzZWN1cml0eSBpc3N1ZXMgdGhhdCBhcHBseSB0byBSRkMgNjEzMCwgaXQgaXMg bm90IGNsZWFyIHdpdGhvdXQgZXh0ZW5zaXZlIHJlYWRpbmcNCiB3aGF0IHRoaXMgZHJhZnQgYWRk cmVzc2VzIHRoYXQgaXMgbm90IChhdCBsZWFzdCBzdWZmaWNpZW50bHkpIGFkZHJlc3NlZCB0aGVy ZSAob3IgaW4gUkZDIDcxODYpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRvd2FyZCB0aGUgZW5kIG9mIHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gc2VjdGlvbiAzIChTTUYg VGhyZWF0cyBPdmVydmlldyksIHRoZSBkcmFmdCBtYWtlcyBhbiBhc3NlcnRpb24gdGhhdCBpcyBu b3QgY29uc2lzdGVudCB3aXRoIG90aGVyIHRleHQgaW4gdGhlIHNhbWUNCiBwYXJhZ3JhcGg7IGl0 IGNsYWltcyB0aGF0IOKAnFNNRiByZWxpZXMgb24gTkhEUOKAnSB3aGlsZSBvdGhlciB0ZXh0LCBp bmNsdWRpbmcgdGV4dCBpbiB0aGUgc2FtZSBwYXJhZ3JhcGgsIHNlZW1zIHN0cm9uZ2x5IHRvIGlu ZGljYXRlIHRoYXQgTkhEUCBpcw0KPHU+b25lIGFsdGVybmF0aXZlIGFwcHJvYWNoIHRoYXQgbWln aHQgYmUgdXNlZDwvdT4uPC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Tm90ZSB0aGF0IEkgd2FzIHVuYWJsZSB0byBwYXJzZSBwYXJ0IG9mIHRoaXMgc2FtZSBzZW50 ZW5jZTogd2hhdCBkb2VzIOKAnChub3QgbWF0dGVyIGlmIG90aGVyIOKApiBmb3IgMS1ob3AgbmVp Z2hib3IgZGlzY292ZXJ5KeKAnSBtZWFuPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TTUYg cmVxdWlyZXMgMS1ob3AgYW5kIDItaG9wIG5laWdoYm91cmhvb2QgaW5mb3JtYXRpb24gdG8gcmVk dWNlIHRoZSByZWxheSBzZXQuIFNNRiBhbGxvd3MgYWx0ZXJuYXRpdmUgbG93LWxheWVyIGluZm9y bWF0aW9uIHRvIHByb3ZpZGUgbmVjZXNzYXJ5IG5laWdoYm91cmhvb2QgaW5mb3JtYXRpb24gLS0g YnV0IHRoYXQncyBvbmx5IGZvciAxLWhvcCBuZWlnaGJvdXJob29kLiBCdXQgZm9yIDItaG9wIG5l aWdoYm91cg0KIGluZm9ybWF0aW9uLCBvbmx5IE5IRFAgaXMgdXNlZCBpbiBTTUYuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjbGFy aWZpZWQgdGhlIGRpZmZlcmVuY2UgaW4gdGhlIHNlY3Rpb24uJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TZWN0 aW9uIDQuMS4xIChSZXBsYXkgQXR0YWNrKSBhcHBlYXJzIHRvIGFkZHJlc3MgYW4gaXNzdWUgdGhh dCBhKSBpcyBub3QgbmVjZXNzYXJpbHkgYSBjb250cm9sIHBsYW5lIGF0dGFjayAoYXMgaW1wbGll ZCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoKSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmFuZCBiKSBpcyBjbGVh cmx5IGEgdmFyaWF0aW9uIG9mIGEgdGhyZWF0IGRlc2NyaWJlZCBpbiB0aGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbiBvZiBSRkMgNjYyMSBhcyBhIERvUyBhdHRhY2suJm5ic3A7IEJl Y2F1c2UgdGhlIHNwZWNpZmljIHRocmVhdCBpbg0KIGJvdGggY2FzZXMgKHRoZSBjYXNlIGRlc2Ny aWJlZCBpbiB0aGlzIHNlY3Rpb24gYW5kIHRoYXQgZGVzY3JpYmVkIGluIFJGQyA2NjIxKSBpbnZv bHZlcyB1c2luZyBzb21lIG1lYW5zIG9mIGRlbGl2ZXJpbmcgYm9ndXMgcGFja2V0cyBlYXJsaWVy IHRoYW4gc3Vic2VxdWVudCBsZWdpdGltYXRlIHBhY2tldHMsIHRoaXMgZG9lcyBub3QgKGF0IGxl YXN0IGludHVpdGl2ZWx5KSBzZWVtIGxpa2UgYSByZXBsYXkgYXR0YWNrLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZSBjaGFuZ2VkIHRoZSBuYW1lIG9mIHRoZSBzZWN0aW9uIHRvIEF0dGFj ayB0byBIb3AgTGltaXQgdG8gYXZvaWQgYW1iaWd1aXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdGlv biA0LjIuMSDigJMgUHJlLWFjdGl2YXRpb24gQXR0YWNrcyAoUHJlLVBsYXkpIOKAkyBzaW1pbGFy bHkgYXBwZWFycyB0byBhZGRyZXNzIG9uZSBzcGVjaWZpYyBleGFtcGxlIG9mIGEgc2Vjb25kIGdl bmVyYWwgY2xhc3Mgb2YgdGhyZWF0IGRlc2NyaWJlZCBpbg0KIHRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uIG9mIFJGQyA2NjIxIChpc3N1ZXMgd2l0aCB1c2Ugb2YgcHJlZGljdGFi bGUgc2VxdWVuY2luZyB0ZWNobmlxdWVzKS4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+VGhlIHNhbWUgYXBwbGllcyB0byBzZWN0aW9uIDQuMi4yIOKAkyBEZS1h Y3RpdmF0aW9uIGF0dGFja3MuJm5ic3A7PC9zcGFuPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+SXQgd291bGQgYmUgdXNlZnVsIGlmIHRoZSBsZWFkaW5nIHRleHQgaW4gc2Vj dGlvbiA0LjIgdGFsa2VkIGdlbmVyYWxseSBhYm91dCB0aGUgcmVsYXRlZCBhdHRhY2sgdmVjdG9y IGRlc2NyaWJlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KIG9mIFJG QyA2NjIxIGFuZCB3aHkgdGhpcyBkcmFmdCBuZWVkcyB0byBleHBhbmQgb24gdGhpcyBjbGFzcyBv ZiB0aHJlYXQgKGFzc29jaWF0ZWQgd2l0aCBJLURQRCkgZGVzY3JpYmVkIHRoZXJlLjwvc3Bhbj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3Rpb24gNC4zIGFsc28gc2lt aWxhcmx5IHByb3ZpZGVzIGFuIGV4cGFuc2lvbiBvbiBhIGNsYXNzIG9mIHRocmVhdHMgKGFzc29j aWF0ZWQgd2l0aCBILURQRCkgYWxyZWFkeSBkZXNjcmliZWQgaW4gUkZDIDY2MjEuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gZ2VuZXJhbCwgSSBmZWVsIHRoYXQgdGhl IGV4cGFuc2lvbnMgcHJvdmlkZWQgaW4gc2VjdGlvbiA0IG9mIHRoaXMgZHJhZnQgcHJvdmlkZSB1 c2VmdWwgaW5mb3JtYXRpb24g4oCTIGFzIGV4YW1wbGVzLCBhdCBsZWFzdC4mbmJzcDsgSG93ZXZl ciwgdGhpcyBzZWN0aW9uIHNob3VsZA0KIGV4cGxpY2l0bHkgcmVmZXIgdG8gYXBwbGljYWJsZSB0 ZXh0IGluIFJGQyA2NjIxLCB3aGljaCBpbmNsdWRlcyBzdWdnZXN0aW9ucyBvbiB3YXlzIHRvIG1p dGlnYXRlIHRoZXNlIHRocmVhdHMuJm5ic3A7IElmIHRoZSBhdXRob3JzIGFuZC9vciB0aGUgd29y a2luZyBncm91cCBmZWVsIHRoYXQgdGhlIHN1Z2dlc3Rpb25zIG1hZGUgaW4gUkZDIDY2MjEgYXJl IGluc3VmZmljaWVudCwgaXQgd291bGQgYmUgdXNlZnVsIHRvIHNheSB3aHkgdGhpcyBpcyB0aGUg Y2FzZQ0KIGluIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFk ZGVkIHJlZmVyZW5jZXMgdG8gcmVsYXRlZCBzZWN0aW9ucyBpbiBSRkM2NjIxIGFuZCBleHBsYWlu ZWQgd2h5IHRob3NlIGFyZSBleHBhbmRlZCBpbiB0aGlzIGRvY3VtZW50IGF0IHRoZSBiZWdpbiBv ZiBzZWN0aW9uIDQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgc2VudGVuY2UgY29tcHJpc2luZyBzZWN0 aW9uIDUuMSAoUmVsYXkgU2V0IFNlbGVjdGlvbiBDb21tb24gVGhyZWF0cykgZG9lcyBub3QgYXBw ZWFyIHRvIGJlIGNvcnJlY3QgYXMgd3JpdHRlbjsgUkZDIDcxODYgZG9lcyBub3QgaW5jbHVkZSBh bnl0aGluZyBhYm91dA0KIFJTUyBhbGdvcml0aG1zLiZuYnNwOyBUbyB0aGUgZXh0ZW50IHRoYXQg UlNTIE1BWSBkZXBlbmQgb24gTkhEUCwgUkZDIDcxODYgZG9lcyBkZXNjcmliZSB0aHJlYXRzIHRv IE5IRFAgdGhhdCB3b3VsZCBpbXBhY3QgUlNTIGZvciB0aGVzZSBjYXNlcy4mbmJzcDsgQXJndWFi bHkgdGhlIHNhbWUgdGhyZWF0cyBtYXkgYXBwbHkgaW5kZXBlbmRlbnQgb2YgaG93IFNNRiByb3V0 ZXJzIGJlY29tZSBhd2FyZSBvZiB0aGUgbmVpZ2hib3Job29kIHRvcG9sb2d5LCBidXQgdGhpcw0K IGlzIG5vdCAoYW5kIHBvc3NpYmx5IGNhbm5vdCBiZSkga25vd24gd2l0aG91dCBleGhhdXN0aXZl IGFuYWx5c2lzIG9mIGFsbCBtZXRob2RzIGJ5IHdoaWNoIHRoaXMgaW5mb3JtYXRpb24gbWlnaHQg YmUgZGV0ZXJtaW5lZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFJTUyBpcyBiYXNl ZCBvbiB0aGUgbmVpZ2hib3VyaG9vZCBpbmZvcm1hdGlvbiBvYnRhaW5lZCBmcm9tIHRoZSBjb250 cm9sIHBsYW5lLiBGb3IgU01GLCBhcyBmYXIgYXMgSSBjYW4gc2VlLCBvbmx5IE5IRFAgaXMgdXNl ZCBpbiBwcmFjdGljZSB0byBvYnRhaW4gbmVpZ2hib3VyaG9vZCBpbmZvcm1hdGlvbi4gU28gdGhl IGNvbW1vbiB0aHJlYXRzIGxpc3RlZCBpbiBzZWN0aW9uIDUuMSBzdWNoIGFzIERvUywNCiBlYXZl c2Ryb3BwaW5nLCBldGMuIGNhbiBiZSBhcHBsaWVkIHRvIFNNRiBkaXJlY3RseSAtLSB0aGF0J3Mg YWxzbyBvbmUgb2YgdGhlIHB1cnBvc2Ugb2YgaGF2aW5nIFJGQzcxODYgYXMgYW4gaW5kZXBlbmRl bnQgZG9jdW1lbnQ6IHJlbGF0ZWQgY29udGVudCBjYW4gYmUgcmV1c2VkIGJ5IHByb3RvY29scyBz dWNoIGFzIFNNRiBhbmQgT0xTUnYyLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JbiBTZWN0aW9uIDUuMiAo VGhyZWF0cyB0byBFLUNEUyBBbGdvcml0aG0pLCBSRkMgNTYxNCBpcyBnaXZlbiBhcyBhIHJlZmVy ZW5jZSBmb3Ig4oCcRXNzZW50aWFsIENvbm5lY3RlZCBEb21pbmF0aW5nIFNldOKAnSAob3IgdGhl IEUtQ0RTIGFsZ29yaXRobSksIHdoZW4gUkZDDQogNTYxNCBhY3R1YWxseSBkb2VzIG5vdCBtZW50 aW9uIGVpdGhlciBvbmUgKGl0IGRlZmluZXMgQ0RTIGFuZCB0YWxrcyBhYm91dCBhIHNtYWxsIG51 bWJlciBvZiBhbGdvcml0aG1zIOKAkyBub25lIG9mIHdoaWNoIGFyZSBkaXJlY3RseSByZWxhdGVk IHRvIEUtQ0RTOyB0aGUgd29yZCDigJxlc3NlbnRpYWzigJ0gZG9lcyBub3QgYXBwZWFyIHRvIGJl IGluY2x1ZGVkIGluIHRoZSBSRkMgYW55d2hlcmUpLiZuYnNwOyBJIHdhcyBub3QgYWJsZSB0byBm aW5kIGEgcmVmZXJlbmNlDQogZm9yIHRoaXMgdGVybSBpbiBhIGZldyBtaW51dGVzIG9mIHBva2lu ZyBhcm91bmQsIHRob3VnaCBpdCBpcyBlYXN5IGVub3VnaCB0byBmaW5kIHJlZmVyZW5jZXMgZm9y IOKAnG1pbmltdW0gY29ubmVjdGVkIGRvbWluYXRpbmcgc2V0LuKAnTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBSRkM2NjIxLCBSRkM1NjE0IGlzIGNpdGVkIHdoZW4gdGhlIEUtQ0RTIGlz IGludHJvZHVjZWQ6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7VGhlICZxdW90O0Vzc2VudGlhbCBD b25uZWN0ZWQgRG9taW5hdGluZyBTZXQmcXVvdDsgKEUtQ0RTKSBhbGdvcml0aG0gW1JGQzU2MTRd PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7Zm9ybXMgYSBzaW5nbGUgQ0RTIG1lc2ggZm9yIHRoZSBTTUYgb3BlcmF0aW5nIHJl Z2lvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbHRob3VnaCZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ 4oCcRXNzZW50aWFsIENvbm5lY3RlZCBEb21pbmF0aW5nIFNldOKAnSBpcyBub3QmbmJzcDtleHBs aWNpdGx5IHVzZWQgaW4gUkZDNTYxNCwgYXMgYSBkZXJpdmF0aXZlLCBJIHRoaW5rIGl0J3Mgc3Rp bGwgYXBwcm9wcmlhdGUgKGFuZCBldmVuIG5lY2Vzc2FyeSkgdG8gY2l0ZSB0aGUgb3JpZ2luYWwm bmJzcDtzb3VyY2U/Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIHNlY3Rpb24gKHNlY3Rpb24gNykgb2YgdGhpcyBkcmFmdCBzaG91bGQgcHJvdmlkZSBh IHN1bW1hcnkgb2Ygc2VjdXJpdHkgaXNzdWVzIGluY2x1ZGVkIG9yIGFkZHJlc3NlZCBpbiB0aGlz IGRvY3VtZW50IChkaXJlY3RseQ0KIG9yIGluZGlyZWN0bHkgYnkgcmVmZXJlbmNlKSBhcyB3ZWxs IGFzIGFueSByZWxhdGVkIHNlY3VyaXR5IGlzc3VlcyB5ZXQgdG8gYmUgYWRkcmVzc2VkLiBNaW5p bWFsbHksIGlmIHRoZSBhdXRob3JzIGZlZWwgdGhhdCB0aGlzIGluZm9ybWF0aW9uIGlzIHByb3Zp ZGVkIGluIHNlY3Rpb24gMyAoU01GIFRocmVhdHMgT3ZlcnZpZXcpLCB0aGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbiBzaG91bGQgc2F5IHRoaXMuJm5ic3A7IE9uZSBhcHByb2FjaA0K IHdvdWxkIGJlIHRvIHVzZSB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0byBz dW1tYXJpemUgdGhlIG1haW4gY29udGVudCBvZiB0aGUgZG9jdW1lbnQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkJ5IHRha2luZyBjb25zaWRlcmF0aW9uIG9mIHRoZSBjb21tZW50cyBmcm9t IEFELCB3ZSBzdW1tYXJpc2VkIHRoZSBjb250ZW50IG9mIHRoZSBkb2N1bWVudCBhbmQgbWVyZ2Vk IHRoZSAmcXVvdDtmdXR1cmUgd29yayZxdW90OyBzZWN0aW9uIGluIHRoaXMgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgc2VjdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk5pdHM6DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SSBoYWQgYSBudW1iZXIgb2YgaXNzdWVzIHdpdGgg4oCcZXNvdGVyaWMgcXVlc3Rpb25zIG9m IEVuZ2xpc2ggdXNhZ2Uu4oCdIEhvd2V2ZXIsIGFjY29yZGluZyB0byBvdXIgaW5zdHJ1Y3Rpb25z LCDigJx0aGUgUkZDIEVkaXRvciB3aWxsIHNwb3QgdGhlc2UsIGFuZCBpdCBpcw0KIG5vdCBhIHdp c2UgdXNlIG9mIHRpbWUgdG8gZGlzY3VzcyB0aGVzZSB0aGluZ3Mu4oCdPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SRkMgZWRpdG9yIGlzIHRoZSBiZXN0 IHRlYWNoZXIgdG8gdGVsbCB1cyBob3cgdG8gd3JpdGUgRW5nbGlzaCBjb3JyZWN0bHkgLS0gZXNw ZWNpYWxseSBmb3Igbm9uLW5hdGl2ZSBFbmdsaXNoIHNwZWFrZXJzIGxpa2UgbWUgOik8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGFn YWluIGZvciB5b3VyIGNvbW1lbnRzISEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaWF6aTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibGFjayI+Sjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_48E1A67CB9CA044EADFEAB87D814BFF64A8ADBF9eusaamb107erics_-- From nobody Thu Sep 8 13:23:37 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6157C12B117; Thu, 8 Sep 2016 13:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.03 X-Spam-Level: X-Spam-Status: No, score=-16.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6GCJ_mqxiuN; Thu, 8 Sep 2016 13:23:34 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CAA2127077; Thu, 8 Sep 2016 13:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2238; q=dns/txt; s=iport; t=1473366213; x=1474575813; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cfIs0L/fD/Pr9x+YFCmJH7tcVI4mU0B7U5kRQr+q8Bg=; b=USE61l9W2AKLxqflkwY8REYTZ7GVC5J/kXWCvRTg65dGrBlel9Ap0HWt 5LB0OLq38ak0DiydVBEeHcl0ZIBe1fPTAy0TMlEI0+KUpQmdvtVXkjNzs yh5BAN9AJ1C8Vxyt/5Qt5zsbkyqeeLw6iVQOqQty8C/ydpB5dWUav+qKg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAQDMx9FX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgy0BAQEBAXV8AY0yqxKCAySFeAKCFhQBAgEBAQEBAQFeJ4RiAQEEIw8BBUA?= =?us-ascii?q?BEAsUBAICBRYLAgIJAwIBAgFFBgEMAQcBAYhGDrESjCYBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEcgQaFKoROh0KCWgEEmV6GIokegW5OhBGDNYVbjFGDex42gmwbgU8?= =?us-ascii?q?6NYdiAQEB?= X-IronPort-AV: E=Sophos;i="5.30,302,1470700800"; d="scan'208";a="645436375" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2016 20:23:31 +0000 Received: from as-lnx.cisco.com (ams-asmirnov-nitro5.cisco.com [10.55.206.134]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u88KNVfs008919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 8 Sep 2016 20:23:31 GMT Message-ID: <57D1C8C1.6020505@cisco.com> Date: Thu, 08 Sep 2016 22:23:29 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ben Niven-Jenkins , rtg-ads@ietf.org References: <627E28A3-CA72-47CF-914B-3DDBC043CBEA@niven-jenkins.co.uk> In-Reply-To: <627E28A3-CA72-47CF-914B-3DDBC043CBEA@niven-jenkins.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: asmirnov Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-lisp-ddt@tools.ietf.org, lisp@ietg.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-ddt-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 20:23:35 -0000 Hello Ben, thanks for your comments (and for very useful list of places in the document requiring improvements). Authors of the draft have addressed questions raised in the review and -08 revision of the draft has been uploaded. Please give another pass to the document; hopefully now it is more strict in defining intended behavior and easier to read. Anton On 08/02/2016 12:06 PM, Ben Niven-Jenkins 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-lisp-ddt-07.txt > Reviewer: Ben Niven-Jenkins > Review Date: 2nd August 2016 > Intended Status: Experimental > > > Summary: > I have some minor concerns about this document that I think should be resolved before publication. > > Comments: > I found the document to be easily readable even though I am not well versed in LISP. > > Minor issues: > 1) The document appears quite light on RFC2119 language (MUST/SHOULD). There are probably areas of the protocol specification that may benefit from more use of RFC2119 language. > > To give one example: Section 7.3.2 says "this Map-Reply will indicate the least-specific XEID-prefix matching the requested XEID for which no delegations exist and will have a TTL value of 15 minutes.” is that really a “SHOULD [or MUST?] have a TTL value of 15 minutes”? > > 2) In a few places the document refers to a “proxy Map-Reply service” without really explaining what it is. A description in the terminology section would help, or a reference to another document that defines the term. > > > HTH > Ben > > From nobody Thu Sep 8 14:03:25 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF6512B258; Thu, 8 Sep 2016 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] 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 n6xPIi3miANz; Thu, 8 Sep 2016 14:03:15 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 8248C12B0CA; Thu, 8 Sep 2016 14:03:15 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id s131so90239146oie.2; Thu, 08 Sep 2016 14:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UjpFVFvIE2uXflcL07c6LmkSCfqlgKob5QTeyEXQB60=; b=dRt3fMQdrONRQUUCV5MKM7cBuBRFyrZzvSbGLXYLs8oyKzUSxcSfv9hjaaVw9pvhBd NtQ1i823aXpuJa8W2gLRQf2Z7FSS/cxUFA4bBIo6CblHkAlHMMwIn6gBxwn88QTn03BJ X+7ORkzUffpoyPY5hxliOZIolTSIt6Zh8bktA0knKKj0p4hu95Q3qK3M7d7X3oX5bxY1 j1adWVBi7DlL6/MiAQUq8BSAoZRuigdjTFv48G1BYYf5Dc/lLE7RxenJaIAp/PYp6GXn Q8CNpCSHRZv9zT9jL1/8MG8PR/esF2JLFTvrOox4j+M3w4APKQMdUJtDR9f/YJGi+xhV KSDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UjpFVFvIE2uXflcL07c6LmkSCfqlgKob5QTeyEXQB60=; b=GSlgTAatHpkhDRHWI6butd5RzfYxobykphvrUhYYxCp9VFoK74sXAJJID85eM2dE2C xBL7+vta8RyYHH7tIxZz6u4AHoB+bBlYeKz8okHjAbmme48sJB6QTu60qQMoZc3jtY78 9qvhXIGHtDP6GfBXzQkk+Otu7O2IgdIJMFHikI8wWCnNhhyya2AeGLTLjU2e+SWD037D okXN5ZA60Nc5NWRfgtW0w2od48RkOGuj+WWF4vJGZgCQsRNK11iVIUclmJm1xf3upLqz o4ZCV94RDbM/dMvm251jTz6uicYOPhWSvgWtATCEvg0Olocp4S3FsMiAwMWB3s86yrYJ uWMg== X-Gm-Message-State: AE9vXwMufu3cTs8X0dY5q1g3H0YDaXlQJIaPpC6wTO1fhW5NuoO4izBIpzNVtcHyauvE2A== X-Received: by 10.202.235.9 with SMTP id j9mr2516333oih.103.1473368594014; Thu, 08 Sep 2016 14:03:14 -0700 (PDT) Received: from [172.19.131.158] ([12.130.117.42]) by smtp.gmail.com with ESMTPSA id g12sm232173iog.33.2016.09.08.14.02.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Sep 2016 14:03:10 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Thu, 8 Sep 2016 14:02:54 -0700 Message-Id: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> References: To: Stig Venaas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, Dino Farinacci , LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2016 21:03:23 -0000 --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Document: draft-ietf-lisp-lcaf-14.txt > Reviewer: Stig Venaas > Review Date: 2016-09-07 > IETF LC End Date: > Intended Status: Experimental Thanks Stig for your comments. See responses below. As well as a new = version -15 not submitted yet but for your quick review. Also find a = lcaf-rfcdiff.html file for easy diff viewing. > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. >=20 > The draft is almost ready but there are several places where the text > is a bit unclear, No problem. This document has had a long history and many opinions = related to it has come and gone but we tried to reflect everyone=E2=80=99s= point of view. > In section 1 I find this sentence a bit misleading since [AFI] doesn't > talk about the formatting. >=20 > Currently defined AFIs include IPv4 and IPv6 addresses, which are > formatted according to code-points assigned in [AFI] as follows: >=20 > Is the formatting shown here for AFI 1 and 2 defined in another > document? It would be good to have a reference. If it is introduced > in this document, then it should not be in the introduction. No it is not shown in any document. All the AFI document says is that a = 16-bit AFI value of 1 means an IP address follows. That means 4 bytes of = address. And 16 for IPv6 when AFI is 2. As you can see the reference to the AFI document is at the end of the = sentence. > In section 2, first paragraph it says: > There is an address family currently defined for IPv4 or IPv6 > addresses. >=20 > It would be better to say that address families are defined for IPv4 > and IPv6 addresses. Changed. > In section 3 we have this paragraph: >=20 > The Address Family AFI definitions from [AFI] only allocate code- > points for the AFI value itself. The length of the address or = entity > that follows is not defined and is implied based on conventional > experience. Where the LISP protocol uses LISP Canonical Addresses > specifically, the address length definitions will be in this > specification and take precedent over any other specification. >=20 > I'm not sure what conventional experience means. Please try to find a Well like I said above, the AFI values defined in the AFI document are = just type values and there is no length defined. So =E2=80=9Cconventional = wisdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we = know what follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. > better way to say it. Regarding the last sentence, what if a you want > to define new LCAF encodings in the future? Is it good to say that = this > specification takes precedent over any other? LCAF encodings and definitions do not change the length of an AFI = encoded address. So I am not sure what you mean. > In section 3 we have this paragraph: >=20 > Length: this 16-bit field is in units of bytes and covers all of = the > LISP Canonical Address payload, starting and including the byte > after the Length field. So any LCAF encoded address will have a > minimum length of 8 bytes when the Length field is 0. The 8 = bytes > include the AFI, Flags, Type, Reserved, and Length fields. When > the AFI is not next to encoded address in a control message, then > the encoded address will have a minimum length of 6 bytes when = the > Length field is 0. The 6 bytes include the Flags, Type, = Reserved, > and Length fields. >=20 > Can you phrase this differently? First it says that any LCAF encoded No not really. It is precise up to the sentence =E2=80=9CWhen the AFI is = not ..=E2=80=9D.=20 > address has a minimum length of 8, but then it goes on to say how it > sometimes is only 6. I understand what you're trying to say, but there=20= > may be a better way of stating it. This special case is for some LISP control-messages where the AFI is = another place in the message but the address is somewhere else. Rather = than have the AFI appear twice, the LCAF length needs to be different. The length field always includes the entire contiguous set of LCAF bytes = including type, flags, length field, etc. The language is precise and accurate. Let me know how you think stating = what I did in this comment response can be put in without writing a lot = of text about a special case. > In section 3 it says: >=20 > Rsvd2: this 8-bit field is reserved for future use and MUST be > transmitted as 0 and ignored on receipt. >=20 > Some of the LCAFs specified in this document are using it though. = Hence > you may need to change this text, and maybe not make it reserved. I change to say the field is LCAF Type dependent and check the LCAF Type = definition to see what bits of this field is not reserved. > The last sentence of section 3 is: >=20 > Therefore, when a locator-set has a mix of AFI records and > LCAF records, all LCAF records will appear after all the AFI = records. >=20 > This is not necessarily true. Isn't it possible that one at some point > in the future might use other AFI records that have AFI > 16387? IANA > has assigned several values beyond 16387. I will change to order must be in AFI value order. > In 4.1 it says: > AFI =3D x: x can be any AFI value from [AFI]. >=20 > Is 16387 always or sometimes allowed? Might be good to clarify that. > This also applies > to all the other LCAF types with similar language. Always. And since 16387 is in [AFI] and the sentence above says =E2=80=9Cc= an be any AFI value from [AFI]=E2=80=9D that implies it can be an LCAF = AFI. If I said =E2=80=9Cincluding the LCAF AFI, I would have to make = this change in a dozen places and would be repetitive. > Section 4.4: >=20 > RTR RLOC Address: this is an encapsulation address used by an ITR = or > PITR which resides behind a NAT device. This address is known to > have state in a NAT device so packets can flow from it to the = LISP > ETR behind the NAT. There can be one or more NAT Tunnel Router > (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in = these > set of fields. The number of NTRs encoded is determined by the > LCAF length field. When there are no NTRs supplied, the NTR > fields can be omitted and reflected by the LCAF length field or = an > AFI of 0 can be used to indicate zero NTRs encoded. >=20 > It is not quite clear to me if the NTR fields here are the RTR RLOC > addresses. Does no NTR fields mean that there are no RTR RLOC = addresses? > If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length > 0), and that would have AFI 0? Good catch. NTR was an old term and the NAT-traversal draft now uses the = term RTR. I will fix. > Section 4.5 first paragraph: >=20 > Multicast group information can be published in the mapping = database. > So a lookup on an group address EID can return a replication list of > RLOC group addresses or RLOC unicast addresses. >=20 > Can you have a mix of group addresses and unicast addresses? It's also Yes, it just depends what address you put following the AFI value. > not so clear from the format what source prefixes are. Are the source I will state that when an (S,G) is encoded that is what the source = address field is used for. > prefixes the same as the unicast RLOCs mentioned above? Can you have > both multiple source addresses and then multiple group addresses? Can > they be in arbitrarty order, or all sources followed by all groups? As shown it is not a list. And if the AFI=3D0 precedes the Source/Subnet = Address field it means there is no source address encoded. > It seems one will need to inspect the address itself to tell whether = it > is a unicast or multicast address. This is probably fine. Right. > Section 4.6 > Add description of Rsvd3. >=20 > Section 4.7 > Add description of Rsvd3 and Rsvd4. Changed. > Section 4.10 > In this section there are several examples of using the AFI List Type, > but I miss a general definition. It appears that there can be a = variable > number of AFIs in the list. Any number > 0? It might be useful to have Yes, a variable number.=20 > a length field associated with each AFI, or is it OK that parsing = fails if > an AFI is unknown, so that the address length is not known? Well each AFI has an implicit length per address entry and the LCAF Type = length has the total length. So why would we need to have yet another = length and complicate parsing even more? Please be aware (and I=E2=80=99m = sure you are being a senior coder), that the more fields you add to = parse, the more cross-checking of field semantics and lengths have to be = done. This really complicates the code and if part of the LCAF Type is = parseable and others are not, then you have a question about what you = use and what you discard. > Section 4.10.3 > Isn't it unusual to include the 0 termination? Since you know the > length it is not really needed. When parsing one will need to check > the length either way, what should one do it the string accidentally > is not 0-terminated? Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate = the string. But the length field will imply it. However, I wrote the = =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is = used (not only in a LCAF but by itself), how to terminate the string. I = could include that reference, but that draft is not a working group = document. So please advise. > Section 4.10.4 > I'm assuming that the recursion is more generic than this example? Yes. > It might be worth trying to explain the more generic concept and > format, and make sure that this is described as just an example. I think that can raise too many combinations. It will be hard to explain = why someone will want to recurse a lot unless we have a well defined = use-case. The fact that an LCAF has an AFI value. It means that an LCAF = can be encoded wherever an AFI value is allowed. This section shows a practical example and not a general one that no one = would know how to use. > Section 4.10.5 > This also appears to be just an example. But a useful one that is already implemented in cisco code. > Section 5.2 > Key Field Num: the number of fields (minus 1) the key can be broken > up into. The width of the fields are fixed length. So for a key > size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 > bytes in length. Allowing for a reasonable number of 16 field > separators, valid values range from 0 to 15. >=20 > It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates > 5 fields? I fixed the description to be more clear. > Key Wildcard Fields: describes which fields in the key are not used > as part of the key lookup. This wildcard encoding is a bitfield. > Each bit is a don't-care bit for a corresponding field in the = key. > Bit 0 (the low-order bit) in this bitfield corresponds the first > field, right-justified in the key, bit 1 the second field, and so > on. When a bit is set in the bitfield it is a don't-care bit and >=20 > What does right-justified mean? Does it mean that the first field is = the > "low order" one? Basically at the end of the message? And the highest Yes, I will make that more clear. > order bit corresponds to the part of the key right after the wilcards? > I think this need to be explained better to ensure interoperability. >=20 > Key: the variable length key used to do a LISP Database Mapping > lookup. The length of the key is the value n (shown above) minus > 3. >=20 > Isn't it exactly the value n, since the length is n + 3? Yes, you are right. Fixed. > Section 5.4 > Length value n: length in bytes of fields that follow. > This is a bit confusing. I think 2+n is the length in bytes that = follow > the lenght field. While n is the number of bytes after the JSON = length. The 2 is for the JSON length field, since it is a fixed field. The = =E2=80=9Cn=E2=80=9D is for the remaining variable length fields which = include the JSON-binary-text and the AFI address. I=E2=80=99ll make the = Length description reflect this. Thanks. > Section 5.5 >=20 > It says "AFI =3D x" twice in the diagram. Based on this and the way it > is described it might seem that the two AFI values must be the same > value x, but they can differ, right? I this applies to several other > messages types as well. I=E2=80=99ll change x to y in the second occurence and a description for = each. > Section 7 > It looks like the table in the IANA considerations doesn't include all > the types defined in this document. That was done intentionally. The ones that are experimental are not in = this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. > I'm happy to discuss my comments if needed, and also review any > updates to this draft. >=20 > Stig Let me know about the response where I didn=E2=80=99t make any changes. Thanks again, Dino/Dave/Job --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-15.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-15.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: March 12, 2017 Brocade J. Snijders NTT Communications September 8, 2016 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-15 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 12, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Farinacci, et al. Expires March 12, 2017 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.5. Multicast Group Membership Information . . . . . . . . . 14 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 16 4.7. Storing Security Data in the Mapping Database . . . . . . 17 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19 4.9. Replication List Entries for Multicast Forwarding . . . . 21 4.10. Applications for AFI List Type . . . . . . . . . . . . . 22 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26 5. Experimental LISP Canonical Address Applications . . . . . . 27 5.1. Convey Application Specific Data . . . . . . . . . . . . 27 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 28 5.3. PETR Admission Control Functionality . . . . . . . . . . 30 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 40 Farinacci, et al. Expires March 12, 2017 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 41 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 12, 2017 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 IPv6 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. Address families are defined for IPv4 and IPv6. See [AFI] and [RFC3232] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Farinacci, et al. Expires March 12, 2017 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). This section defines all types for which an initial allocation in the LISP-LCAF registry is requested. See IANA Considerations section for the complete list of such types. The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification. The first 6 bytes of an LISP Canonical Address are followed by a variable number of fields of variable length: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, currently allocated values are: Type 0: Null Body Type Type 1: AFI List Type Farinacci, et al. Expires March 12, 2017 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Type 16: Encapsulation Format Type Rsvd2: this LCAF Type dependent 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. See specific LCAF Type for specific bits not reserved. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. [RFC6830] states RLOC records are sorted when encoded in control messages so the locator-set has consistent order across all xTRs for a given EID. The sort order is based on sort-key {afi, RLOC- address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- Farinacci, et al. Expires March 12, 2017 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Type}. Therefore, when a locator-set has a mix of AFI records and LCAF records, they are ordered from smallest to largest AFI value. 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Farinacci, et al. Expires March 12, 2017 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The reason for the length difference is so that the maximum number of instances supported per mapping system is 2^32 while conserving space in the LISP data header. This comes at the expense of limiting the maximum number of instances per xTR to 2^24. If an xTR is configured with multiple instance-IDs where the value in the high-order 8 bits are the same, then the low-order 24 bits MUST be unique. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Usage: When used as a lookup key, the EID is regarded as a extended- EID in the mapping system. This encoding is used in EID records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.3. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Farinacci, et al. Expires March 12, 2017 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Altitude: Height relative to sea level in meters. This is a signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.4. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details. NAT-Traversal Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires March 12, 2017 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Reencapsulating Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of RTRs encoded is determined by the LCAF length field. When there are no RTRs supplied, the RTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero RTRs encoded. Usage: This encoding can be used in Info-Request and Info-Reply messages. The mapping system does not store this information. The information is used by an xTR and Map-Server to convey private and public address information when traversing NAT and firewall devices. Farinacci, et al. Expires March 12, 2017 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.5. Multicast Group Membership Information Multicast group information can be published in the mapping database. So a lookup on an group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels according to [I-D.coras-lisp-re]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Source MaskLen: the mask length of the source prefix that follows. Farinacci, et al. Expires March 12, 2017 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Source/Subnet Address is the source address or prefix for encoding a (S,G) multicast entry. Group Address is the group address or group prefix for encoding (S,G) or (*,G) multicast entries. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 12, 2017 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.6. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [I-D.farinacci-lisp-te] for details. Explicit Locator Path (ELP) Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can be reachable. Strict bit (S): this is the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires March 12, 2017 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. This encoding does not need to be understood by the mapping system for mapping database lookups since this LCAF type is not a lookup key. 4.7. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [I-D.ietf-lisp-ddt] for details. Farinacci, et al. Expires March 12, 2017 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Security Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. Rsvd4: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires March 12, 2017 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 4.8. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Farinacci, et al. Expires March 12, 2017 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Source/Dest Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Refer to [I-D.farinacci-lisp-te] for usage details of this LCAF type. Farinacci, et al. Expires March 12, 2017 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.9. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [I-D.coras-lisp-re]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level within the overlay distribution tree hierarchy where the RTR resides. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. For efficiency reasons, all RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 12, 2017 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10. Applications for AFI List Type 4.10.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry multiple AFIs in one LCAF AFI. Address Binding LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. See subsections in this section for specific use cases. Farinacci, et al. Expires March 12, 2017 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. See [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when doing EID mobility. Farinacci, et al. Expires March 12, 2017 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). Farinacci, et al. Expires March 12, 2017 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCAF AFI another LCAF AFI (for example, Application Specific Data see Section 5.1. Recursive LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires March 12, 2017 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 14 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires March 12, 2017 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5. Experimental LISP Canonical Address Applications 5.1. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended Farinacci, et al. Expires March 12, 2017 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 EIDs are used in Map-Referral messages. This LCAF type is used as a lookup key to the mapping system that can return a longest-match or exact-match entry. 5.2. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | 3 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Farinacci, et al. Expires March 12, 2017 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Key Field Num: the value of this field is the the number of "Key" sub-fields minus 1, the "Key" field can be broken up into. So if this field has a value of 0, there is 1 sub-field in the "Key". The width of the sub-fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes each in length. Allowing for a reasonable number of 16 sub- field separators, valid values range from 0 to 15. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, the low-order field in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (as shown above). Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 12, 2017 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.3. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. This nonce value is inserted in the nonce field in the LISP header encapsulation. AFI =3D x: x can be any AFI value from [AFI]. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 12, 2017 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.4. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 14 | Rsvd2 |B| 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON length | JSON binary/text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the fields that follow the "JSON length" field. Rsvd{1,2}: must be set to zero and ignore on receipt. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC7159]. JSON length: length in octets of the following 'JSON binary/text encoding' field. JSON binary/text encoding field: a variable length field that contains either binary or text encodings. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 12, 2017 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.5. Encoding Key/Value Address Pairs The Key/Value pair is for example useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 15 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D y | Address as Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. AFI =3D x: x is the "Address as Key" AFI that can have any value = from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Address as Key: this AFI encoded address will be attached with the attributes encoded in "Address as Value" which follows this field. AFI =3D y: y is the "Address of Value" AFI that can have any value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Value: this AFI encoded address will be the attribute address that goes along with "Address as Key" which precedes this field. Farinacci, et al. Expires March 12, 2017 [Page 32] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This is an experimental type where the usage has not been defined yet. 5.6. Multiple Data-Planes Overlays are becoming popular in many parts of the network which have created an explosion of data-plane encapsulation headers. Since the LISP mapping system can hold many types of address formats, it can represent the encapsulation format supported by an RLOC as well. When an encapsulator receives a Map-Reply with an Encapsulation Format LCAF Type encoded in an RLOC-record, it can select an encapsulation format, that it can support, from any of the encapsulation protocols which have the bit set to 1 in this LCAF type. Farinacci, et al. Expires March 12, 2017 [Page 33] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Encapsulation Format Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 16 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1/Rsvd2: must be set to zero and ignored on receipt. Length value n: length in bytes of the AFI address that follows the next 32-bits including the AFI field itself. Reserved-for-Future-Encapsulations: must be set to zero and ignored on receipt. This field will get bits allocated to future encapsulations, as they are created. L: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer3 LISP encapsulation using destination UDP port 4341 [RFC6830]. l: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer2 LISP encapsulation using destination UDP port 8472 [I-D.smith-lisp-layer2]. V: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN encapsulation using destination UDP port 4789 [RFC7348]. v: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN-GPE encapsulation using destination UDP port 4790 [I-D.quinn-vxlan-gpe]. N: The RLOCs listed in the AFI encoded addresses in the next longword can accept NV-GRE encapsulation using IPv4/ IPv6 protocol number 47 [RFC7637]. G: The RLOCs listed in the AFI encoded addresses in the next longword can accept GENEVE encapsulation using destination UDP port 6081 [I-D.gross-geneve]. Farinacci, et al. Expires March 12, 2017 [Page 34] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 U: The RLOCs listed in the AFI encoded addresses in the next longword can accept GUE encapsulation using destination UDP port TBD [I-D.herbert-gue]. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 12, 2017 [Page 35] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 6. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. The use of the Geo-Coordinates LCAF Type may raise physical privacy issues. Care should be taken when configuring the mapping system to use specific policy parameters so geo-location information is not returned gratutiosly. 7. IANA Considerations This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Such address format is based on a fixed AFI (16387) and a LISP LCAF Type field. The LISP LCAF Type field is an 8-bit field specific to the LISP Canonical Address formatted encodings, for which IANA is to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP LCAF Type". Initial values for the LISP LCAF Type registry are given below. Future assignments are to be made through expert review with a specification required publication. Assignments consist of a LISP LCAF Type name and its associated value: +-------+------------------------------+------------+ | Value | LISP LCAF Type Name | Definition | +-------+------------------------------+------------+ | 0 | Null Body Type | Section 3 | | 1 | AFI List Type | Section 3 | | 2 | Instance ID Type | Section 3 | | 3 | AS Number Type | Section 3 | | 5 | Geo Coordinates Type | Section 3 | | 7 | NAT-Traversal Type | Section 3 | | 9 | Multicast Info Type | Section 3 | | 10 | Explicit Locator Path Type | Section 3 | | 11 | Security Key Type | Section 3 | | 12 | Source/Dest Key Type | Section 3 | | 13 | Replication List Entry Type | Section 3 | +-------+------------------------------+------------+ Table 1: LISP LCAF Type Initial Values Farinacci, et al. Expires March 12, 2017 [Page 36] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . Farinacci, et al. Expires March 12, 2017 [Page 37] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8.2. Informative References [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [I-D.coras-lisp-re] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-08 (work in progress), November 2015. [I-D.ermagan-lisp-nat-traversal] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan- lisp-nat-traversal-11 (work in progress), August 2016. [I-D.farinacci-lisp-te] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-11 (work in progress), September 2016. [I-D.gross-geneve] Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Generic Network Virtualization Encapsulation", draft- gross-geneve-02 (work in progress), October 2014. [I-D.herbert-gue] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", draft-herbert-gue-03 (work in progress), March 2015. [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- ddt-07 (work in progress), May 2016. [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- mobility-00 (work in progress), April 2016. Farinacci, et al. Expires March 12, 2017 [Page 38] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 [I-D.quinn-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-04 (work in progress), February 2015. [I-D.smith-lisp-layer2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 (L2) LISP Encapsulation Format", draft-smith-lisp- layer2-03 (work in progress), September 2013. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires March 12, 2017 [Page 39] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-lcaf-15.txt o Submitted September 2016. o Addressed comments from Routing Directorate reviewer Stig Venass. B.2. Changes to draft-ietf-lisp-lcaf-14.txt o Submitted July 2016. o Fix IDnits errors and comments from Luigi Iannone, document shepherd. B.3. Changes to draft-ietf-lisp-lcaf-13.txt o Submitted May 2016. o Explain the Instance-ID LCAF Type is 32-bits in length and the Instance-ID field in the LISP encapsulation header is 24-bits. B.4. Changes to draft-ietf-lisp-lcaf-12.txt o Submitted March 2016. o Updated references and document timer. o Removed the R, J, and L bits from the Multicast Info Type LCAF since working group decided to not go forward with draft- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- signal-free-00.txt. B.5. Changes to draft-ietf-lisp-lcaf-11.txt o Submitted September 2015. o Reflecting comments from Prague LISP working group. o Readying document for a LISP LCAF registry, RFC publication, and for new use-cases that will be defined in the new charter. Farinacci, et al. Expires March 12, 2017 [Page 40] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt o Submitted June 2015. o Fix coauthor Job's contact information. B.7. Changes to draft-ietf-lisp-lcaf-09.txt o Submitted June 2015. o Fix IANA Considerations section to request a registry to allocate and track LCAF Type values. B.8. Changes to draft-ietf-lisp-lcaf-08.txt o Submitted April 2015. o Comment from Florin. The Application Data Type length field has a typo. The field should be labeled "12 + n" and not "8 + n". o Fix length fields in the sections titled "Using Recursive LISP Canonical Address Encodings", "Generic Database Mapping Lookups", and "Data Model Encoding". B.9. Changes to draft-ietf-lisp-lcaf-07.txt o Submitted December 2014. o Add a new LCAF Type called "Encapsulation Format" so decapsulating xTRs can inform encapsulating xTRs what data-plane encapsulations they support. B.10. Changes to draft-ietf-lisp-lcaf-06.txt o Submitted October 2014. o Make it clear how sorted RLOC records are done when LCAFs are used as the RLOC record. B.11. Changes to draft-ietf-lisp-lcaf-05.txt o Submitted May 2014. o Add a length field of the JSON payload that can be used for either binary or text encoding of JSON data. Farinacci, et al. Expires March 12, 2017 [Page 41] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.12. Changes to draft-ietf-lisp-lcaf-04.txt o Submitted January 2014. o Agreement among ELP implementors to have the AFI 16-bit field adjacent to the address. This will make the encoding consistent with all other LCAF type address encodings. B.13. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.14. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.15. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.16. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires March 12, 2017 [Page 42] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ NL Email: job@ntt.net Farinacci, et al. Expires March 12, 2017 [Page 43] --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Disposition: attachment; filename=lcaf-rfcdiff.html Content-Type: text/html; name="lcaf-rfcdiff.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-lcaf-14.txt - = draft-ietf-lisp-lcaf-15.txt=20 =20 =20 =20 =20 =20 =20= = = = = =
< draft-ietf-lisp-lcaf-14.txt  =  draft-ietf-lisp-lcaf-15.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental D. Meyer = Intended status: Experimental = D. Meyer
Expires: January 20, 2017 = Brocade Expires: March 12, 2017 = Brocade
= J. Snijders = J. Snijders
= NTT Communications = NTT Communications
= July = 19, 2016 = September = 8, 2016
=
= LISP Canonical Address Format (LCAF) = LISP Canonical Address Format (LCAF)
= draft-ietf-lisp-lcaf-14 = = draft-ietf-lisp-lcaf-15
=
Abstract = Abstract
=
This draft = defines a canonical address format encoding used in LISP = This draft defines a canonical address = format encoding used in LISP
control = messages and in the encoding of lookup keys for the LISP = control messages and in the encoding of = lookup keys for the LISP
Mapping = Database System. Mapping Database = System.
=
Requirements = Language Requirements Language
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
=
skipping to = change at = page 1, line 41 =C2=B6 = skipping to change at page 1, line 41 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on January 20, = 2017. This Internet-Draft will = expire on March 12, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 23 =C2=B6 = skipping to change at page 2, line 23 =C2=B6
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
3. LISP = Canonical Address Format Encodings . . . . . . . . . . . 5 = 3. LISP Canonical Address Format Encodings = . . . . . . . . . . . 5
4. LISP = Canonical Address Applications . . . . . . . . . . . . . 7 = 4. LISP Canonical Address Applications . . = . . . . . . . . . . . 7
4.1. = Segmentation using LISP . . . . . . . . . . . . . . . . . 7 = 4.1. Segmentation using LISP . . . . . . = . . . . . . . . . . . 7
4.2. = Carrying AS Numbers in the Mapping Database . . . . . . . 9 = 4.2. Carrying AS Numbers in the Mapping = Database . . . . . . . 9
4.3. = Assigning Geo Coordinates to Locator Addresses . . . . . 10 = 4.3. Assigning Geo Coordinates to Locator = Addresses . . . . . 10
4.4. NAT = Traversal Scenarios . . . . . . . . . . . . . . . . . 12 = 4.4. NAT Traversal Scenarios . . . . . . = . . . . . . . . . . . 12
4.5. = Multicast Group Membership Information . . . . . . . . . 14 = 4.5. Multicast Group Membership = Information . . . . . . . . . 14
4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 15 4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 16
4.7. = Storing Security Data in the Mapping Database . . . . . . 17 = 4.7. Storing Security Data in the Mapping = Database . . . . . . 17
4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 18 4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19
4.9. = Replication List Entries for Multicast Forwarding . . . . 20 4.9. = Replication List Entries for Multicast Forwarding . . . . 21
4.10. = Applications for AFI List Type . . . . . . . . . . . . . 21 4.10. = Applications for AFI List Type . . . . . . . . . . . . . 22
4.10.1. = Binding IPv4 and IPv6 Addresses . . . . . . . . . . 21 = 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22
4.10.2. = Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 22 = 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23
4.10.3. = ASCII Names in the Mapping Database . . . . . . . . 23 = 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24
4.10.4. = Using Recursive LISP Canonical Address Encodings . . 24 = 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25
4.10.5. = Compatibility Mode Use Case . . . . . . . . . . . . 25 = 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26
5. = Experimental LISP Canonical Address Applications . . . . . . 26 5. = Experimental LISP Canonical Address Applications . . . . . . 27
5.1. = Convey Application Specific Data . . . . . . . . . . . . 26 5.1. = Convey Application Specific Data . . . . . . . . . . . . 27
5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 27 5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 28
5.3. PETR = Admission Control Functionality . . . . . . . . . . 29 5.3. = PETR Admission Control Functionality . . . . . . . . . . 30
5.4. Data = Model Encoding . . . . . . . . . . . . . . . . . . . 30 5.4. = Data Model Encoding . . . . . . . . . . . . . . . . . . . 31
5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 31 5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 32
5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 32 5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33
6. Security = Considerations . . . . . . . . . . . . . . . . . . . 34 6. = Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. = Normative References . . . . . . . . . . . . . . . . . . 35 8.1. = Normative References . . . . . . . . . . . . . . . . . . 37
8.2. = Informative References . . . . . . . . . . . . . . . . . 36 8.2. = Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 37 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 38 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-lcaf-14.txt . = . . . . . . . . 38 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . = 40
B.2. = Changes to draft-ietf-lisp-lcaf-13.txt . = . . . . . . . . 38 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . = 40
B.3. = Changes to draft-ietf-lisp-lcaf-12.txt . = . . . . . . . . 38 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . = 40
B.4. = Changes to draft-ietf-lisp-lcaf-11.txt . = . . . . . . . . 38 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . = 40
B.5. = Changes to draft-ietf-lisp-lcaf-10.txt . = . . . . . . . . 38 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . = 40
B.6. = Changes to draft-ietf-lisp-lcaf-09.txt . = . . . . . . . . 39 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . = 41
B.7. = Changes to draft-ietf-lisp-lcaf-08.txt . = . . . . . . . . 39 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . = 41
B.8. = Changes to draft-ietf-lisp-lcaf-07.txt . = . . . . . . . . 39 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . = 41
B.9. = Changes to draft-ietf-lisp-lcaf-06.txt . = . . . . . . . . 39 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . = 41
B.10. = Changes to draft-ietf-lisp-lcaf-05.txt . = . . . . . . . . 39 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . = 41
B.11. = Changes to draft-ietf-lisp-lcaf-04.txt . = . . . . . . . . 39 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . = 41
B.12. = Changes to draft-ietf-lisp-lcaf-03.txt . = . . . . . . . . 40 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . = 42
B.13. = Changes to draft-ietf-lisp-lcaf-02.txt . = . . . . . . . . 40 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . = 42
B.14. = Changes to draft-ietf-lisp-lcaf-01.txt . = . . . . . . . . 40 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . = 42
B.15. = Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 40 B.15. = Changes to draft-ietf-lisp-lcaf-01.txt . . . . . = . . . . 42
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 B.16. Changes to = draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 43
=
1. = Introduction 1. Introduction
=
The LISP = architecture and protocols [RFC6830] introduces two new = The LISP architecture and protocols = [RFC6830] introduces two new
numbering = spaces, Endpoint Identifiers (EIDs) and Routing Locators = numbering spaces, Endpoint Identifiers = (EIDs) and Routing Locators
(RLOCs). To = provide flexibility for current and future applications, = (RLOCs). To provide flexibility for current = and future applications,
these values = can be encoded in LISP control messages using a general = these values can be encoded in LISP control = messages using a general
syntax that = includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), = length, and
value = fields. value fields.
=
=
skipping to = change at = page 4, line 28 =C2=B6 = skipping to change at page 4, line 28 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
This document = describes the currently-defined AFIs the LISP protocol This document describes the currently-defined AFIs = the LISP protocol
uses along = with their encodings and introduces the LISP Canonical uses along with their encodings and introduces the = LISP Canonical
Address Format = (LCAF) that can be used to define the LISP-specific Address Format (LCAF) that can be used to define the = LISP-specific
encodings for = arbitrary AFI values. encodings for = arbitrary AFI values.
=
2. Definition of = Terms 2. Definition of Terms
=
Address Family = Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to = describe an address
encoding = in a packet. There is an address family = currently encoding in a = packet. Address families are defined for = IPv4 and
defined = for IPv4 or IPv6 addresses. See [AFI] and = [RFC3232] for = IPv6. See [AFI] and [RFC3232] for details. The reserved = AFI
details. = The reserved AFI value of 0 is used in this value of 0 is used in this specification to = indicate an
= specification to indicate an unspecified encoded address where = the unspecified encoded address = where the length of the address is 0
length of = the address is 0 bytes following the 16-bit AFI value of = bytes following the 16-bit AFI value of = 0.
= 0.
=
Unspecified = Address Format: Unspecified Address = Format:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 0 | <nothing follows AFI=3D0> | = | AFI =3D 0 | = <nothing follows AFI=3D0> |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Endpoint ID = (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value = Endpoint ID (EID): a 32-bit (for IPv4) or = 128-bit (for IPv6) value
=
skipping to = change at = page 6, line 34 =C2=B6 = skipping to change at page 6, line 34 =C2=B6
Type 12: = Source/Dest Key Type Type 12: = Source/Dest Key Type
=
Type 13: = Replication List Entry Type Type = 13: Replication List Entry Type
=
Type 14: = JSON Data Model Type Type 14: = JSON Data Model Type
=
Type 15: = Key/Value Address Pair Type Type = 15: Key/Value Address Pair Type
=
Type 16: = Encapsulation Format Type Type = 16: Encapsulation Format Type
=
Rsvd2: this = 8-bit field is reserved for future use and MUST be Rsvd2: this LCAF Type = dependent 8-bit field is reserved for future
= transmitted as 0 and ignored on receipt. use and MUST be transmitted as 0 and ignored on = receipt. See
= specific LCAF = Type for specific bits not reserved.
=
Length: this = 16-bit field is in units of bytes and covers all of the = Length: this 16-bit field is in units of = bytes and covers all of the
LISP = Canonical Address payload, starting and including the byte = LISP Canonical Address payload, starting = and including the byte
after the = Length field. So any LCAF encoded address will have a after the Length field. So any LCAF encoded = address will have a
minimum = length of 8 bytes when the Length field is 0. The 8 bytes = minimum length of 8 bytes when the Length = field is 0. The 8 bytes
include the = AFI, Flags, Type, Reserved, and Length fields. When include the AFI, Flags, Type, Reserved, and Length = fields. When
the AFI is = not next to encoded address in a control message, then the AFI is not next to encoded address in a = control message, then
the encoded = address will have a minimum length of 6 bytes when the the encoded address will have a minimum length of = 6 bytes when the
Length = field is 0. The 6 bytes include the Flags, Type, Reserved, = Length field is 0. The 6 bytes include = the Flags, Type, Reserved,
and Length = fields. and Length = fields.
=
[RFC6830] = states RLOC records are sorted when encoded in control [RFC6830] states RLOC records are sorted when encoded = in control
messages so = the locator-set has consistent order across all xTRs for = messages so the locator-set has consistent = order across all xTRs for
a given EID. = The sort order is based on sort-key {afi, RLOC- a given EID. The sort order is based on sort-key = {afi, RLOC-
address}. When = an RLOC is LCAF encoded, the sort-key is {afi, LCAF- address}. When an RLOC is LCAF encoded, the sort-key = is {afi, LCAF-
Type}. = Therefore, when a locator-set has a mix of AFI records and = Type}. Therefore, when a locator-set has a = mix of AFI records and
LCAF = records, all LCAF records will appear after all = the AFI records. LCAF = records, they are ordered from smallest to = largest AFI value.
=
4. LISP = Canonical Address Applications 4. = LISP Canonical Address Applications
=
4.1. = Segmentation using LISP 4.1. = Segmentation using LISP
=
When multiple = organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are = using private
addresses = [RFC1918] as EID-prefixes, their address spaces must remain = addresses [RFC1918] as EID-prefixes, their = address spaces must remain
segregated due = to possible address duplication. An Instance ID in segregated due to possible address duplication. An = Instance ID in
the address = encoding can aid in making the entire AFI based address = the address encoding can aid in making the = entire AFI based address
= unique. unique.
=
skipping to = change at = page 13, line 12 =C2=B6 = skipping to change at page 13, line = 12 =C2=B6
MS RLOC = Address: this is the address of the Map-Server used in the = MS RLOC Address: this is the address of the = Map-Server used in the
destination = RLOC of a packet that has flowed through a NAT device. destination RLOC of a packet that has flowed = through a NAT device.
=
Private ETR = RLOC Address: this is an address known to be a private = Private ETR RLOC Address: this is an = address known to be a private
address = inserted in this LCAF format by a LISP router that resides = address inserted in this LCAF format by a = LISP router that resides
on the = private side of a NAT device. on = the private side of a NAT device.
=
RTR RLOC = Address: this is an encapsulation address used by an ITR or = RTR RLOC Address: this is an encapsulation = address used by an ITR or
PITR which = resides behind a NAT device. This address is known to PITR which resides behind a NAT device. This = address is known to
have state = in a NAT device so packets can flow from it to the LISP = have state in a NAT device so packets can = flow from it to the LISP
ETR = behind the NAT. There can be one or more NAT Tunnel Router = ETR behind the NAT. There can be one or = more NAT Reencapsulating
(NTR) [I-D.ermagan-lisp-nat-traversal] addresses = supplied in these Tunnel Router = (RTR) [I-D.ermagan-lisp-nat-traversal] = addresses
set of = fields. The number of NTRs encoded is = determined by the supplied in = these set of fields. The number of RTRs = encoded is
LCAF = length field. When there are no NTRs = supplied, the NTR determined by the LCAF length field. When there = are no RTRs
fields = can be omitted and reflected by the LCAF length field or an = supplied, the RTR fields can be omitted and reflected by the = LCAF
AFI of 0 = can be used to indicate zero NTRs = encoded. length field or an AFI = of 0 can be used to indicate zero RTRs
= encoded.
=
Usage: This = encoding can be used in Info-Request and Info-Reply Usage: This encoding can be used in Info-Request and = Info-Reply
messages. The = mapping system does not store this information. The messages. The mapping system does not store this = information. The
information is = used by an xTR and Map-Server to convey private and information is used by an xTR and Map-Server to = convey private and
public address = information when traversing NAT and firewall devices. public address information when traversing NAT and = firewall devices.
=
4.5. Multicast = Group Membership Information 4.5. = Multicast Group Membership Information
=
Multicast = group information can be published in the mapping database. = Multicast group information can be published = in the mapping database.
So a lookup on = an group address EID can return a replication list of So a lookup on an group address EID can return a = replication list of
=
skipping to = change at = page 15, line 11 =C2=B6 = skipping to change at page 15, line = 11 =C2=B6
of = (Instance-ID, S-prefix, G-prefix). = of (Instance-ID, S-prefix, G-prefix).
=
Source = MaskLen: the mask length of the source prefix that follows. = Source MaskLen: the mask length of the = source prefix that follows.
=
Group MaskLen: = the mask length of the group prefix that follows. Group MaskLen: the mask length of the group prefix = that follows.
=
AFI =3D x: x = can be any AFI value from [AFI]. When a specific AFI has = AFI =3D x: x can be any AFI value from = [AFI]. When a specific AFI has
its own = encoding of a multicast address, this field must be either = its own encoding of a multicast address, = this field must be either
a group = address or a broadcast address. = a group address or a broadcast address.
=
= Source/Subnet = Address is the source address or prefix for encoding a
= (S,G) multicast = entry.
=
= Group Address is = the group address or group prefix for encoding
= (S,G) or (*,G) = multicast entries.
= =
Usage: This = encoding can be used in EID records in Map-Requests, Map- = Usage: This encoding can be used in EID = records in Map-Requests, Map-
Replies, = Map-Registers, and Map-Notify messages. When LISP-DDT Replies, Map-Registers, and Map-Notify messages. = When LISP-DDT
= [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, = extended [I-D.ietf-lisp-ddt] is = used as the mapping system mechanism, extended
EIDs are used = in Map-Referral messages. EIDs are = used in Map-Referral messages.
=
4.6. Traffic = Engineering using Re-encapsulating Tunnels 4.6. Traffic Engineering using Re-encapsulating = Tunnels
=
For a given = EID lookup into the mapping database, this LCAF format For a given EID lookup into the mapping database, = this LCAF format
can be = returned to provide a list of locators in an explicit re- = can be returned to provide a list of = locators in an explicit re-
encapsulation = path. See [I-D.farinacci-lisp-te] for details. encapsulation path. See [I-D.farinacci-lisp-te] for = details.
=
skipping to = change at = page 16, line 25 =C2=B6 = skipping to change at page 16, line = 31 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop 1 ... | | Reencap Hop 1 ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Rsvd3 |L|P|S| AFI =3D x | = | Rsvd3 |L|P|S| = AFI =3D x |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop k ... | | Reencap Hop k ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Lookup bit = (L): this is the Lookup bit used to indicate to the user = Lookup bit (L): this is the Lookup bit used = to indicate to the user
of the ELP = to not use this address for encapsulation but to look of the ELP to not use this address for = encapsulation but to look
it up in = the mapping database system to obtain an encapsulating it up in the mapping database system to obtain an = encapsulating
RLOC = address. RLOC address.
=
RLOC-Probe bit = (P): this is the RLOC-probe bit which means the RLOC-Probe bit (P): this is the RLOC-probe bit which = means the
Reencap Hop = allows RLOC-probe messages to be sent to it. When the Reencap Hop allows RLOC-probe messages to be sent = to it. When the
R-bit is = set to 0, RLOC-probes must not be sent. When a Reencap = R-bit is set to 0, RLOC-probes must not = be sent. When a Reencap
Hop is an = anycast address then multiple physical Reencap Hops are = Hop is an anycast address then multiple = physical Reencap Hops are
using the = same RLOC address. In this case, RLOC-probes are not using the same RLOC address. In this case, = RLOC-probes are not
=
skipping to = change at = page 17, line 35 =C2=B6 = skipping to change at page 18, line = 29 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Locator Address ... | | AFI =3D x | Locator = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that start with the Key Length value n: length in bytes of fields that start = with the Key
Material = field. Material field.
=
Key Count: = the Key Count field declares the number of Key sections = Key Count: the Key Count field declares the = number of Key sections
included in = this LCAF. included in this = LCAF.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Key Algorithm: = the Algorithm field identifies the key's Key Algorithm: the Algorithm field identifies the = key's
= cryptographic algorithm and specifies the format of the Public = Key cryptographic algorithm and = specifies the format of the Public Key
= field. field.
=
= Rsvd4: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
R bit: this = is the revoke bit and, if set, it specifies that this R bit: this is the revoke bit and, if set, it = specifies that this
Key is = being Revoked. Key is being = Revoked.
=
Key Length: = this field determines the length in bytes of the Key Key Length: this field determines the length in = bytes of the Key
Material = field. Material field.
=
Key Material: = the Key Material field stores the key material. The Key Material: the Key Material field stores the key = material. The
format of = the key material stored depends on the Key Algorithm format of the key material stored depends on the = Key Algorithm
= field. field.
=
=
skipping = to change at page 28, line = 5 =C2=B6 = skipping to change at page 29, line = 5 =C2=B6
| Type =3D 6 = | Rsvd2 | 3 + n | | Type =3D 6 | Rsvd2 | 3 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Field = Num | Key Wildcard Fields | Key . . . | | Key Field Num | Key Wildcard Fields | = Key . . . |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Key | | . . . Key = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of the type's payload. The value n = Length value n: length in bytes of the = type's payload. The value n
is the = number of bytes that follow this Length field. is the number of bytes that follow this Length = field.
=
Key Field = Num: the number of fields (minus 1) the = key can be broken Key Field Num: the value of = this field is the the number of "Key"
up into. = The width of the fields are fixed length. = So for a key = sub-fields minus 1, the "Key" = field can be broken up into. So = if
size of 8 = bytes, with a Key Field Num of 4 allows 4 = fields of 2 this field has a value of = 0, there is 1 sub-field in the "Key".
bytes in = length. Allowing for a reasonable number of 16 field The width of the sub-fields are fixed length. So for a key = size
= separators, valid values range from 0 to 15. of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2
= bytes each = in length. Allowing for a reasonable number of 16 sub-
= field separators, valid values range = from 0 to 15.
=
Key Wildcard = Fields: describes which fields in the key are not used = Key Wildcard Fields: describes which fields = in the key are not used
as part of = the key lookup. This wildcard encoding is a bitfield. as part of the key lookup. This wildcard encoding = is a bitfield.
Each bit is = a don't-care bit for a corresponding field in the key. Each bit is a don't-care bit for a corresponding = field in the key.
Bit 0 (the = low-order bit) in this bitfield corresponds the first Bit 0 (the low-order bit) in this bitfield = corresponds the first
field, = right-justified in the key, bit 1 the = second field, and so field, = the low-order field in the key, bit 1 the = second field, and
on. When = a bit is set in the bitfield it is a don't-care bit and = so on. When a bit is set in the = bitfield it is a don't-care bit
should = not be considered as part of the database lookup. When the = and should not be considered as part of = the database lookup. When
entire = 16-bits is set to 0, then all bits of the key are used for = the entire 16-bits is set to 0, then all = bits of the key are used
the = database lookup. for the = database lookup.
=
Key: the = variable length key used to do a LISP Database Mapping Key: the variable length key used to do a LISP = Database Mapping
lookup. = The length of the key is the value n (shown = above) minus lookup. = The length of the key is the value n (as shown = above).
3.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.3. PETR = Admission Control Functionality 5.3. = PETR Admission Control Functionality
=
When a public = PETR device wants to verify who is encapsulating to it, = When a public PETR device wants to verify = who is encapsulating to it,
it can check = for a specific nonce value in the LISP encapsulated it can check for a specific nonce value in the LISP = encapsulated
packet. To = convey the nonce to admitted ITRs or PITRs, this LCAF packet. To convey the nonce to admitted ITRs or = PITRs, this LCAF
format is used = in a Map-Register or Map-Reply locator-record. format is used in a Map-Register or Map-Reply = locator-record.
=
skipping = to change at page 30, line = 24 =C2=B6 = skipping to change at page 31, line = 24 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 14 | Rsvd2 |B| 2 + n | | Type =3D 14 | Rsvd2 |B| 2 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = JSON length | JSON binary/text encoding ... | | JSON length | JSON binary/text = encoding ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Optional Address ... | | AFI =3D x | Optional = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. = Length value n: length in bytes of the = fields that follow the "JSON
= length" = field.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
B bit: = indicates that the JSON field is binary encoded according to = B bit: indicates that the JSON field is = binary encoded according to
= [JSON-BINARY] when the bit is set to 1. Otherwise the encoding = is [JSON-BINARY] when the bit is = set to 1. Otherwise the encoding is
based on = text encoding according to [RFC7159]. = based on text encoding according to [RFC7159].
=
JSON length: = length in octets of the following 'JSON binary/text JSON length: length in octets of the following 'JSON = binary/text
encoding' = field. encoding' field.
=
=
skipping = to change at page 31, line = 26 =C2=B6 = skipping to change at page 32, line = 26 =C2=B6
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 15 | Rsvd2 | n | | Type =3D 15 | Rsvd2 | n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as Key ... | | AFI =3D x | Address as = Key ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as = Value ... | | AFI = =3D y | Address as Value = ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
AFI =3D x: = x can be any AFI value from [AFI]. A specific AFI has = its AFI =3D x: x is the "Address as Key" AFI that can have any value from
own = encoding of either a unicast or multicast locator address. = [AFI]. A specific AFI has its own = encoding of either a unicast or
All = RTR/ETR entries for the same level should be combined together = multicast locator address. All RTR/ETR = entries for the same level
by a = Map-Server to avoid searching through the entire multi-level = should be combined together by a = Map-Server to avoid searching
list of = locator entries in a Map-Reply = message. through the entire = multi-level list of locator entries in a Map-
= Reply = message.
=
Address as = Key: this AFI encoded address will be attached with the = Address as Key: this AFI encoded address = will be attached with the
attributes = encoded in "Address as Value" which follows this field. = attributes encoded in "Address as Value" = which follows this field.
=
= AFI =3D y: y is the = "Address of Value" AFI that can have any value
= from [AFI]. A = specific AFI has its own encoding of either a
= unicast or = multicast locator address. All RTR/ETR entries for the
= same level should = be combined together by a Map-Server to avoid
= searching through = the entire multi-level list of locator entries
= in a Map-Reply = message.
= =
Address as = Value: this AFI encoded address will be the attribute Address as Value: this AFI encoded address will be = the attribute
address = that goes along with "Address as Key" which precedes this = address that goes along with "Address as = Key" which precedes this
= field. field.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.6. Multiple = Data-Planes 5.6. Multiple = Data-Planes
=
Overlays are = becoming popular in many parts of the network which have = Overlays are becoming popular in many parts = of the network which have
=
skipping = to change at page 36, line = 19 =C2=B6 = skipping to change at page 38, line = 19 =C2=B6
=
= [I-D.coras-lisp-re] = [I-D.coras-lisp-re]
= Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., = Domingo-Pascual, J.,
= Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP = Replication
= Engineering", draft-coras-lisp-re-08 (work in progress), = Engineering", = draft-coras-lisp-re-08 (work in progress),
= November 2015. November = 2015.
=
= [I-D.ermagan-lisp-nat-traversal] = [I-D.ermagan-lisp-nat-traversal]
= Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, = Ermagan, V., Farinacci, D., = Lewis, D., Skriver, J., Maino,
F., = and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for = LISP", draft-ermagan-
= lisp-nat-traversal-10 (work in progress), = February 2016. = lisp-nat-traversal-11 (work in progress), = August 2016.
=
= [I-D.farinacci-lisp-te] = [I-D.farinacci-lisp-te]
= Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Farinacci, D., Kowal, M., and P. Lahiri, = "LISP Traffic
= Engineering Use-Cases", draft-farinacci-lisp-te-10 (work = Engineering Use-Cases", draft-farinacci-lisp-te-11 (work
= in progress), March 2016. = in progress), September 2016.
=
= [I-D.gross-geneve] = [I-D.gross-geneve]
= Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., = Gross, J., Sridhar, T., Garg, P., = Wright, C., Ganga, I.,
= Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: = Agarwal, P., Duda, K., Dutt, D., = and J. Hudson, "Geneve:
= Generic Network Virtualization Encapsulation", draft- Generic Network Virtualization = Encapsulation", draft-
= gross-geneve-02 (work in progress), October 2014. gross-geneve-02 (work in progress), = October 2014.
=
= [I-D.herbert-gue] = [I-D.herbert-gue]
= Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, = "Generic UDP
= Encapsulation", draft-herbert-gue-03 (work in progress), = Encapsulation", = draft-herbert-gue-03 (work in progress),
=
skipping = to change at page 38, line = 9 =C2=B6 = skipping to change at page 40, line = 9 =C2=B6
Thanks goes to = Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto = Rodriguez-Natal for
suggesting new = LCAF types. suggesting new LCAF = types.
=
Thanks also = goes to Terry Manderson for assistance obtaining a LISP = Thanks also goes to Terry Manderson for = assistance obtaining a LISP
AFI value from = IANA. AFI value from IANA.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-lcaf-14.txt B.1. = Changes to draft-ietf-lisp-lcaf-15.txt
=
= o Submitted = September 2016.
=
= o Addressed = comments from Routing Directorate reviewer Stig Venass.
=
= B.2. Changes to = draft-ietf-lisp-lcaf-14.txt
=
o Submitted = July 2016. o Submitted July = 2016.
=
o Fix IDnits = errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, = document
= shepherd. shepherd.
=
B.2. Changes to = draft-ietf-lisp-lcaf-13.txt B.3. Changes to = draft-ietf-lisp-lcaf-13.txt
=
o Submitted = May 2016. o Submitted May = 2016.
=
o Explain the = Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in = length and the
Instance-ID = field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header = is 24-bits.
=
B.3. Changes to = draft-ietf-lisp-lcaf-12.txt B.4. Changes to = draft-ietf-lisp-lcaf-12.txt
=
o Submitted = March 2016. o Submitted March = 2016.
=
o Updated = references and document timer. o = Updated references and document timer.
=
o Removed the = R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast = Info Type LCAF
since = working group decided to not go forward with draft- since working group decided to not go forward with = draft-
= farinacci-lisp-mr-signaling-03.txt in favor of draft- = ietf-lisp- = farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
= signal-free-00.txt. = signal-free-00.txt.
=
B.4. Changes to = draft-ietf-lisp-lcaf-11.txt B.5. Changes to = draft-ietf-lisp-lcaf-11.txt
=
o Submitted = September 2015. o Submitted = September 2015.
=
o Reflecting = comments from Prague LISP working group. o Reflecting comments from Prague LISP working = group.
=
o Readying = document for a LISP LCAF registry, RFC publication, and = o Readying document for a LISP LCAF = registry, RFC publication, and
for new = use-cases that will be defined in the new charter. for new use-cases that will be defined in the new = charter.
=
B.5. Changes to = draft-ietf-lisp-lcaf-10.txt B.6. Changes to = draft-ietf-lisp-lcaf-10.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix = coauthor Job's contact information. = o Fix coauthor Job's contact information.
=
B.6. Changes to = draft-ietf-lisp-lcaf-09.txt B.7. Changes to = draft-ietf-lisp-lcaf-09.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix IANA = Considerations section to request a registry to allocate = o Fix IANA Considerations section to = request a registry to allocate
and track = LCAF Type values. and track LCAF = Type values.
=
B.7. Changes to = draft-ietf-lisp-lcaf-08.txt B.8. Changes to = draft-ietf-lisp-lcaf-08.txt
=
o Submitted = April 2015. o Submitted April = 2015.
=
o Comment = from Florin. The Application Data Type length field has a = o Comment from Florin. The Application = Data Type length field has a
typo. The = field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and = not "8 + n".
=
o Fix length = fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using = Recursive LISP
Canonical = Address Encodings", "Generic Database Mapping Lookups", = Canonical Address Encodings", "Generic = Database Mapping Lookups",
and "Data = Model Encoding". and "Data Model = Encoding".
=
B.8. Changes to = draft-ietf-lisp-lcaf-07.txt B.9. Changes to = draft-ietf-lisp-lcaf-07.txt
=
o Submitted = December 2014. o Submitted = December 2014.
=
o Add a new = LCAF Type called "Encapsulation Format" so decapsulating = o Add a new LCAF Type called "Encapsulation = Format" so decapsulating
xTRs can = inform encapsulating xTRs what data-plane encapsulations = xTRs can inform encapsulating xTRs what = data-plane encapsulations
they = support. they support.
=
B.9. Changes to = draft-ietf-lisp-lcaf-06.txt B.10. Changes to = draft-ietf-lisp-lcaf-06.txt
=
o Submitted = October 2014. o Submitted October = 2014.
=
o Make it = clear how sorted RLOC records are done when LCAFs are used = o Make it clear how sorted RLOC records are = done when LCAFs are used
as the RLOC = record. as the RLOC = record.
=
B.10. Changes to = draft-ietf-lisp-lcaf-05.txt B.11. Changes to = draft-ietf-lisp-lcaf-05.txt
=
o Submitted = May 2014. o Submitted May = 2014.
=
o Add a = length field of the JSON payload that can be used for either = o Add a length field of the JSON payload = that can be used for either
binary or = text encoding of JSON data. = binary or text encoding of JSON data.
=
B.11. Changes to = draft-ietf-lisp-lcaf-04.txt B.12. Changes to = draft-ietf-lisp-lcaf-04.txt
=
o Submitted = January 2014. o Submitted January = 2014.
=
o Agreement = among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI = 16-bit field
adjacent to = the address. This will make the encoding consistent adjacent to the address. This will make the = encoding consistent
with all = other LCAF type address encodings. = with all other LCAF type address encodings.
=
B.12. Changes to = draft-ietf-lisp-lcaf-03.txt B.13. Changes to = draft-ietf-lisp-lcaf-03.txt
=
o Submitted = September 2013. o Submitted = September 2013.
=
o Updated = references and author's affilations. = o Updated references and author's affilations.
=
o Added = Instance-ID to the Multicast Info Type so there is relative = o Added Instance-ID to the Multicast Info = Type so there is relative
ease in = parsing (S,G) entries within a VPN. = ease in parsing (S,G) entries within a VPN.
=
o Add port = range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data = LCAF Type.
=
o Add a new = JSON LCAF Type. o Add a new JSON = LCAF Type.
=
o Add Address = Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow = attributes to be attached
to an = address. to an address.
=
B.13. Changes to = draft-ietf-lisp-lcaf-02.txt B.14. Changes to = draft-ietf-lisp-lcaf-02.txt
=
o Submitted = March 2013. o Submitted March = 2013.
=
o Added new = LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to = support LISP
replication = engineering use-cases. = replication engineering use-cases.
=
o Changed = references to new LISP RFCs. o = Changed references to new LISP RFCs.
=
B.14. Changes to = draft-ietf-lisp-lcaf-01.txt B.15. Changes to = draft-ietf-lisp-lcaf-01.txt
=
o Submitted = January 2013. o Submitted January = 2013.
=
o Change = longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in = section 4.4.
=
o Added = reference to WGS-84 in section 4.4. = o Added reference to WGS-84 in section 4.4.
=
B.15. Changes to = draft-ietf-lisp-lcaf-00.txt B.16. Changes to = draft-ietf-lisp-lcaf-00.txt
=
o Posted = first working group draft August 2012. = o Posted first working group draft August 2012.
=
o This draft = was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from = draft-farinacci-lisp-lcaf-10.txt.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = CA San Jose, CA
 End of changes. 38 change blocks. 
95 lines changed or = deleted 128 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F14C54DF-FC1E-47EB-B6F8-161931C27CC9-- From nobody Fri Sep 9 08:33:38 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B86B12B122; Fri, 9 Sep 2016 07:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, 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 HU-CxCGo1ENX; Fri, 9 Sep 2016 07:46:15 -0700 (PDT) Received: from mgw020.noc.ntt.com (mgw020.noc.ntt.com [210.160.55.2]) by ietfa.amsl.com (Postfix) with ESMTP id A074E12B166; Fri, 9 Sep 2016 07:46:08 -0700 (PDT) Received: from c0042i0.coe.ntt.com (c0042i0.nc.agilit-hosting.com [10.18.161.11]) by mgw020.noc.ntt.com (NTT Com MailSV) with ESMTP id 97255446159E; Fri, 9 Sep 2016 23:46:07 +0900 (JST) Received: from C0041I0.coe.ntt.com (10.18.160.45) by c0042i0.coe.ntt.com (10.18.161.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 9 Sep 2016 23:46:07 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.161]) by C0041I0.coe.ntt.com ([10.18.160.45]) with mapi id 14.03.0181.006; Fri, 9 Sep 2016 23:46:07 +0900 From: Tomonori Takeda To: "'rtg-ads@ietf.org'" Thread-Topic: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt Thread-Index: AdIKqDg5BThlaDp0Suq7kh+dmeZr1A== Date: Fri, 9 Sep 2016 14:46:05 +0000 Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: rtg-ads@ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-pce-stateful-pce-app@ietf.org, pce@ietf.org x-originating-ip: [10.25.166.50] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: Cc: "'rtg-dir@ietf.org'" , "'pce@ietf.org'" , "'draft-ietf-pce-stateful-pce-app@ietf.org'" Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 14:46:23 -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-pce-stateful-pce-app-06.txt Reviewer: Tomonori Takeda Review Date: September 9th, 2016 IETF LC End Date: Not known Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document describes applicability of a stateful PCE, as well as general considerations for deployment. The document is well organized and easy to read. However, there are some minor points which I think should be clarified for completeness and easiness to ready. Major Issues: None Minor Issues: 1) In page 5, section 4.1, multi-PCE deployments are described. It says, "Regardless of the reason for multiple PCEs, an LSP is only delegated to one of the PCEs at any given point in time." Is this described/defined in some other document, or in this document? In the first case, please indicate a reference. In the latter case, I would like to see more clarification and reasoning. 2) In page 12, section 5.1.4, predictability is described as an application. It says "A stateful PCE can solve this through control over LSP ordering.", but I am not sure how stateful PCE solves this scenario. Is it possible even if computation requests come in a time series? Or is it assumed that a stateful PCE is used in such a way that computation requests do not come in a time series? (For example, in a failure scenario, LSP re-computation is not triggered by PCC requesting path computation, but by link failure?) Nits: None Thanks, Tomonori Takeda From nobody Fri Sep 9 16:15:26 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C16F12B028 for ; Fri, 9 Sep 2016 16:15:22 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmjz8iCSPgPl for ; Fri, 9 Sep 2016 16:15:20 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D496912B118 for ; Fri, 9 Sep 2016 16:15:17 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id g62so53774975lfe.3 for ; Fri, 09 Sep 2016 16:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e+VjUqgsVGCpJnnAWCvrL7l8RoM35oSKHIZ7Y+rnExc=; b=zFITBfVPbsj2busSoeUw693vBm97K/RuUZjFqbJnU7wqN/3L2Chc9joNUd+tF0+gBI veuqreaidMGz7usajw++n8zGgnMrCgSoIuPJyyfQuJTfJj2IiZ1rcyiQdCMg98QLz7bn bEmgSvtfbLD5IkI/TjR95+hE6K3LJoxMCKLIQlePo3qouPt1EPvDe44VU+PjlK3oKnrL Cw/8Fol9M8owMC7Mbtd/y9ReikypzlT0nJlj6xXmp4iWoW9iXAPBy6rTvcKPRk92TTLE XsSHtU3LGaLP2r7cZk2xxpT/7T1MBKFGxJYKcdUl+Q0Hz6wbEv7XFZ6aWhtThdkw0hkB D8Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=e+VjUqgsVGCpJnnAWCvrL7l8RoM35oSKHIZ7Y+rnExc=; b=jNAsghMber3+/acuZ2UtEfRWv1A5Ce+E3ZrMuBUFdOt6vsEPoOuCrw9vN2hIGqsZoH LDa0q2MaqqtBWm+T3xyiDnspy0BCjFBR9yRJJH+YzQ75b0nbhmyvHdXZ2yxBo47AAA/v DbIZTKXTTiiDU7QATkxn2W8+YsexvErb8ByxrDva9DhMZd3ZIqtd+rxS96jDwFKclxwa 3XMftAXtrGe1QIjno53c5mSIsOvgHJ7vkihxDrWm9wK4RHklC+fE0fbmBttMh3mN99jY k/zbQ66mXPJHw31xjOqzdJjbk8yEoaGrSHyQYV7g/VxYkizNL8NKq5poIudzM2y9kQvO JsGw== X-Gm-Message-State: AE9vXwOXWmkdEertFlQJoKCVWUT6BIhi9GBiNF97VeDz+9+BYF0kDXUHVFsPhNgDjkGx+iHiGqe4M6ErqJtSaA== X-Received: by 10.25.29.85 with SMTP id d82mr2101062lfd.60.1473462915703; Fri, 09 Sep 2016 16:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.15 with HTTP; Fri, 9 Sep 2016 16:15:14 -0700 (PDT) In-Reply-To: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> From: Stig Venaas Date: Fri, 9 Sep 2016 16:15:14 -0700 Message-ID: To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 23:15:22 -0000 Hi On Thu, Sep 8, 2016 at 2:02 PM, Dino Farinacci wrote: >> Document: draft-ietf-lisp-lcaf-14.txt >> Reviewer: Stig Venaas >> Review Date: 2016-09-07 >> IETF LC End Date: >> Intended Status: Experimental > > Thanks Stig for your comments. See responses below. As well as a new vers= ion -15 not submitted yet but for your quick review. Also find a lcaf-rfcdi= ff.html file for easy diff viewing. Thanks. I have some comments inline. >> Summary: >> I have some minor concerns about this document that I think should be >> resolved before publication. >> >> The draft is almost ready but there are several places where the text >> is a bit unclear, > > No problem. This document has had a long history and many opinions relate= d to it has come and gone but we tried to reflect everyone=E2=80=99s point = of view. > >> In section 1 I find this sentence a bit misleading since [AFI] doesn't >> talk about the formatting. >> >> Currently defined AFIs include IPv4 and IPv6 addresses, which are >> formatted according to code-points assigned in [AFI] as follows: >> >> Is the formatting shown here for AFI 1 and 2 defined in another >> document? It would be good to have a reference. If it is introduced >> in this document, then it should not be in the introduction. > > No it is not shown in any document. All the AFI document says is that a 1= 6-bit AFI value of 1 means an IP address follows. That means 4 bytes of add= ress. And 16 for IPv6 when AFI is 2. > > As you can see the reference to the AFI document is at the end of the sen= tence. > >> In section 2, first paragraph it says: >> There is an address family currently defined for IPv4 or IPv6 >> addresses. >> >> It would be better to say that address families are defined for IPv4 >> and IPv6 addresses. > > Changed. > >> In section 3 we have this paragraph: >> >> The Address Family AFI definitions from [AFI] only allocate code- >> points for the AFI value itself. The length of the address or entity >> that follows is not defined and is implied based on conventional >> experience. Where the LISP protocol uses LISP Canonical Addresses >> specifically, the address length definitions will be in this >> specification and take precedent over any other specification. >> >> I'm not sure what conventional experience means. Please try to find a > > Well like I said above, the AFI values defined in the AFI document are ju= st type values and there is no length defined. So =E2=80=9Cconventional wis= dom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we know what= follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. In theory there should be standards/documents specifying this for each of the address types, and maybe could write that people should see the respective standards or something. I don't know if this exists for all the types though. >> better way to say it. Regarding the last sentence, what if a you want >> to define new LCAF encodings in the future? Is it good to say that this >> specification takes precedent over any other? > > LCAF encodings and definitions do not change the length of an AFI encoded= address. So I am not sure what you mean. The last sentence says "Where the LISP protocol uses LISP Canonical Addresses specifically, the address length definitions will be in this specification and take precedent over any other specification.". What if you in the future would like to write a separate specification that defines additional LISP Canonical address formats? >> In section 3 we have this paragraph: >> >> Length: this 16-bit field is in units of bytes and covers all of the >> LISP Canonical Address payload, starting and including the byte >> after the Length field. So any LCAF encoded address will have a >> minimum length of 8 bytes when the Length field is 0. The 8 bytes >> include the AFI, Flags, Type, Reserved, and Length fields. When >> the AFI is not next to encoded address in a control message, then >> the encoded address will have a minimum length of 6 bytes when the >> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >> and Length fields. >> >> Can you phrase this differently? First it says that any LCAF encoded > > No not really. It is precise up to the sentence =E2=80=9CWhen the AFI is = not ..=E2=80=9D. > >> address has a minimum length of 8, but then it goes on to say how it >> sometimes is only 6. I understand what you're trying to say, but there >> may be a better way of stating it. > > This special case is for some LISP control-messages where the AFI is anot= her place in the message but the address is somewhere else. Rather than hav= e the AFI appear twice, the LCAF length needs to be different. > > The length field always includes the entire contiguous set of LCAF bytes = including type, flags, length field, etc. > > The language is precise and accurate. Let me know how you think stating w= hat I did in this comment response can be put in without writing a lot of t= ext about a special case. The problem I see is that first you write "So any LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0." and then you write "then the encoded address will have a minimum length of 6 bytes when the Length field is 0." I understand what you mean, but I feel this is a bit confusing. Maybe you could say something like: When including the AFI, an LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. Or start by saying that the minimal length is 6, and then say that it will then be 8 when the AFI is included. >> In section 3 it says: >> >> Rsvd2: this 8-bit field is reserved for future use and MUST be >> transmitted as 0 and ignored on receipt. >> >> Some of the LCAFs specified in this document are using it though. Hence >> you may need to change this text, and maybe not make it reserved. > > I change to say the field is LCAF Type dependent and check the LCAF Type = definition to see what bits of this field is not reserved. > >> The last sentence of section 3 is: >> >> Therefore, when a locator-set has a mix of AFI records and >> LCAF records, all LCAF records will appear after all the AFI records. >> >> This is not necessarily true. Isn't it possible that one at some point >> in the future might use other AFI records that have AFI > 16387? IANA >> has assigned several values beyond 16387. > > I will change to order must be in AFI value order. > >> In 4.1 it says: >> AFI =3D x: x can be any AFI value from [AFI]. >> >> Is 16387 always or sometimes allowed? Might be good to clarify that. >> This also applies >> to all the other LCAF types with similar language. > > Always. And since 16387 is in [AFI] and the sentence above says =E2=80=9C= can be any AFI value from [AFI]=E2=80=9D that implies it can be an LCAF AFI= . If I said =E2=80=9Cincluding the LCAF AFI, I would have to make this chan= ge in a dozen places and would be repetitive. I'll leave this to you, but one option could be to just mention it here, and just say that it is true for other types as well. Or mention somewhere before this in the draft that this is allowed. But you already say "any AFI", so that should mean that this is allowed. >> Section 4.4: >> >> RTR RLOC Address: this is an encapsulation address used by an ITR or >> PITR which resides behind a NAT device. This address is known to >> have state in a NAT device so packets can flow from it to the LISP >> ETR behind the NAT. There can be one or more NAT Tunnel Router >> (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these >> set of fields. The number of NTRs encoded is determined by the >> LCAF length field. When there are no NTRs supplied, the NTR >> fields can be omitted and reflected by the LCAF length field or an >> AFI of 0 can be used to indicate zero NTRs encoded. >> >> It is not quite clear to me if the NTR fields here are the RTR RLOC > >> addresses. Does no NTR fields mean that there are no RTR RLOC addresses? >> If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length >> 0), and that would have AFI 0? > > Good catch. NTR was an old term and the NAT-traversal draft now uses the = term RTR. I will fix. > >> Section 4.5 first paragraph: >> >> Multicast group information can be published in the mapping database. >> So a lookup on an group address EID can return a replication list of >> RLOC group addresses or RLOC unicast addresses. >> >> Can you have a mix of group addresses and unicast addresses? It's also > > Yes, it just depends what address you put following the AFI value. > >> not so clear from the format what source prefixes are. Are the source > > I will state that when an (S,G) is encoded that is what the source addres= s field is used for. > >> prefixes the same as the unicast RLOCs mentioned above? Can you have >> both multiple source addresses and then multiple group addresses? Can >> they be in arbitrarty order, or all sources followed by all groups? > > As shown it is not a list. And if the AFI=3D0 precedes the Source/Subnet = Address field it means there is no source address encoded. > >> It seems one will need to inspect the address itself to tell whether it >> is a unicast or multicast address. This is probably fine. > > Right. > >> Section 4.6 >> Add description of Rsvd3. >> >> Section 4.7 >> Add description of Rsvd3 and Rsvd4. > > Changed. > >> Section 4.10 >> In this section there are several examples of using the AFI List Type, >> but I miss a general definition. It appears that there can be a variable >> number of AFIs in the list. Any number > 0? It might be useful to have > > Yes, a variable number. How about adding a few lines of text to 4.10 saying that you can have a variable number etc., explaining briefly what the general format is. And then say that what follows are examples? >> a length field associated with each AFI, or is it OK that parsing fails = if >> an AFI is unknown, so that the address length is not known? > > Well each AFI has an implicit length per address entry and the LCAF Type = length has the total length. So why would we need to have yet another lengt= h and complicate parsing even more? Please be aware (and I=E2=80=99m sure y= ou are being a senior coder), that the more fields you add to parse, the mo= re cross-checking of field semantics and lengths have to be done. This real= ly complicates the code and if part of the LCAF Type is parseable and other= s are not, then you have a question about what you use and what you discard= . I guess I agree with you. Only issue I see is if you at some point need an implementation to be able to parse past an unkown AFI, basically not knowing the expected address length of the AFI. >> Section 4.10.3 >> Isn't it unusual to include the 0 termination? Since you know the >> length it is not really needed. When parsing one will need to check >> the length either way, what should one do it the string accidentally >> is not 0-terminated? > > Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate the= string. But the length field will imply it. However, I wrote the =E2=80=9C= distinguished-name=E2=80=9D draft to specify when AFI=3D17 is used (not onl= y in a LCAF but by itself), how to terminate the string. I could include th= at reference, but that draft is not a working group document. > > So please advise. Currently it says: Length value n: length in bytes AFI=3D17 field and the null-terminated ASCII string (the last byte of 0 is included). It might make sense to 0 terminate the DN in some cases, but at least here we know the string length from the value of n, so I think it would be better to drop it here. And as I mentioned, you cannot rely on the 0 for parsing, to be on the safe side you would use n anyway. >> Section 4.10.4 >> I'm assuming that the recursion is more generic than this example? > > Yes. > >> It might be worth trying to explain the more generic concept and >> format, and make sure that this is described as just an example. > > I think that can raise too many combinations. It will be hard to explain = why someone will want to recurse a lot unless we have a well defined use-ca= se. The fact that an LCAF has an AFI value. It means that an LCAF can be en= coded wherever an AFI value is allowed. > > This section shows a practical example and not a general one that no one = would know how to use. > >> Section 4.10.5 >> This also appears to be just an example. > > But a useful one that is already implemented in cisco code. > >> Section 5.2 >> Key Field Num: the number of fields (minus 1) the key can be broken >> up into. The width of the fields are fixed length. So for a key >> size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 >> bytes in length. Allowing for a reasonable number of 16 field >> separators, valid values range from 0 to 15. >> >> It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates >> 5 fields? > > I fixed the description to be more clear. > >> Key Wildcard Fields: describes which fields in the key are not used >> as part of the key lookup. This wildcard encoding is a bitfield. >> Each bit is a don't-care bit for a corresponding field in the key. >> Bit 0 (the low-order bit) in this bitfield corresponds the first >> field, right-justified in the key, bit 1 the second field, and so >> on. When a bit is set in the bitfield it is a don't-care bit and >> >> What does right-justified mean? Does it mean that the first field is the >> "low order" one? Basically at the end of the message? And the highest > > Yes, I will make that more clear. > >> order bit corresponds to the part of the key right after the wilcards? >> I think this need to be explained better to ensure interoperability. >> >> Key: the variable length key used to do a LISP Database Mapping >> lookup. The length of the key is the value n (shown above) minus >> 3. >> >> Isn't it exactly the value n, since the length is n + 3? > > Yes, you are right. Fixed. > >> Section 5.4 >> Length value n: length in bytes of fields that follow. >> This is a bit confusing. I think 2+n is the length in bytes that follow >> the lenght field. While n is the number of bytes after the JSON length. > > The 2 is for the JSON length field, since it is a fixed field. The =E2=80= =9Cn=E2=80=9D is for the remaining variable length fields which include the= JSON-binary-text and the AFI address. I=E2=80=99ll make the Length descrip= tion reflect this. Thanks. > >> Section 5.5 >> >> It says "AFI =3D x" twice in the diagram. Based on this and the way it >> is described it might seem that the two AFI values must be the same >> value x, but they can differ, right? I this applies to several other >> messages types as well. > > I=E2=80=99ll change x to y in the second occurence and a description for = each. > >> Section 7 >> It looks like the table in the IANA considerations doesn't include all >> the types defined in this document. > > That was done intentionally. The ones that are experimental are not in th= is section 7 list because there is no use-case document for it yet. Maybe t= he chairs can explain this better than me. I think it's still useful. If someone sees the type used, they can look it up in the registry. It also helps avoid that someone perhaps tries to reuse one of these types in new documents. If you really want to use one of the code points for something else in the future, a new document could always update the registry. BTW, it also makes me wonder if it is worth reserving any LCAF types for experiments. Regards, Stig >> I'm happy to discuss my comments if needed, and also review any >> updates to this draft. >> >> Stig > > Let me know about the response where I didn=E2=80=99t make any changes. > > Thanks again, > Dino/Dave/Job > > > > > > > > > From nobody Sat Sep 10 12:00:17 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2348C12B1BA for ; Sat, 10 Sep 2016 12:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 3TkRrGFJL8b8 for ; Sat, 10 Sep 2016 12:00:14 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 4077212B1A0 for ; Sat, 10 Sep 2016 12:00:13 -0700 (PDT) Received: (qmail 3722 invoked by uid 0); 10 Sep 2016 19:00:08 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 10 Sep 2016 19:00:08 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id hv001t02M2SSUrH01v03wk; Sat, 10 Sep 2016 13:00:07 -0600 X-Authority-Analysis: v=2.1 cv=OdYLUHjY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=GW1xBdLrtEIA:10 a=48vgC7mUAAAA:8 a=XOoOPJqTNOX68IEp-SEA:9 a=-no8tr4l1NcWNshe:21 a=1r-fGKjBND-kygWv:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To; bh=sroCJhHrtJcq7daNAUAcLHdK+hYDNuRsLucRvoXld54=; b=C2X87SaGmJahVuPWPMWD8iE9hd yJmYw+XFI/wB0TkbkRPNMGTx7xG2VxNSUULyOOvX3B3H4lgvoGI5DGgivspghedi5RQsV10f1aE3B m1PKIrgnC9KAeJCc5fT3Fq9ID; Received: from box313.bluehost.com ([69.89.31.113]:39474 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1binVQ-0005QX-PN; Sat, 10 Sep 2016 13:00:00 -0600 To: rtg-ads@ietf.org From: Lou Berger Message-ID: Date: Sat, 10 Sep 2016 14:59:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source-IP: 69.89.31.113 X-Exim-ID: 1binVQ-0005QX-PN X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:39474 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "rtg-dir@ietf.org" , draft-ietf-tsvwg-diffserv-intercon.all@ietf.org, tsvwg Subject: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2016 19:00:16 -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-tsvwg-diffserv-intercon-09 Reviewer: Lou Berger Review Date: Sept 10 Intended Status: Informational Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is being published as Informational as such my review and comments focus more on the clarity of the document than its specific recommendations. While the document has no major issues, I think the currently has a number of confusing, if not contradictory, statements that should be clarified prior to publications. There are also a number of other issues, ranging from minor to nit - level, that should also be addressed. Major Issues: No major issues found. Minor Issues: - The first issue is target use / applicability The document title implies that the document scope may apply to any provider interconnection as does 1st sentence of the 3rd paragraph 3 of section 1; IP tunnels are also mentioned in Section 4.3. Yet the Abstract and Section 1.2 state applicability is to MPLS-based providers. Section 4 then further narrows applicability 4 classes of traffic. I think the applicability of this document to both (a) intra-provider technologies and (b) supported traffic classes need to be clarified and consistent across the document's Title, Abstract, Intro/Applicability and other sections. - Use of 'QoS' I find QoS undefined in the document and is really being used synonymously with 'traffic class', 'traffic treatment', 'DSCP', 'Class of Service' and even DiffServ itself in the document. I think the intent and clarity of the document would be improved by removing or replacing all instances of QoS. This would obviate needing to define what QoS means in the context of the specific (and limited) usage of DiffServ, as well as avoid naming consistency with other documents. - Intent of section 2 I found the purpose of Section 2 entirely unclear. This may have been due to some of the confusing text it contains (e.g., the 3rd sentence of the Section - what is non-tunneled IP traffic in an MPLS network, and why would an MPLS provider be tunneling traffic in IP tunnels?) If it's merely to introduce MPLS Short Pipe's and PHP, then this is accomplished in section 1 -- and by RFC3270 itself. If this is the sole purpose, than perhaps it would be easiest/best to just delete the section or combine it with Appendix A. If there is another purpose that is core to the document, I think the text needs to be revised to make that purpose clear, Nits: - The document is inconsistent in how it references RFCs. At times, it expands the RFC as text (e.g., "RFC 2475") other times it uses reference notation (e.g., [RFC5127]) other times it uses both (e.g, RFC 5127 [RFC5127]). Some consistency on use / intent would benefit the document. From nobody Mon Sep 12 05:02:01 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A29F12B256; Mon, 12 Sep 2016 05:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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] 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 81aHXNgt1Hn5; Mon, 12 Sep 2016 05:01:56 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 EF5A312B211; Mon, 12 Sep 2016 05:01:55 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id 128so51820957pfb.3; Mon, 12 Sep 2016 05:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WXK4+MIDry5NK9y+lmB0PCenZwFfuACmO+qMeWG3KfE=; b=VIaXtfWtonMmvjLKHfOrhLm5se5KQclIZRmRtOALELwB0BTa1hGsHzqEsdkvx6jhE+ fMjd9+CqgXA6QtWh9yRfVUU7mghds80BTJ0e4mJBcnt5hMziFIOgFXNG/dfoHYDXbQy5 9zwlEosFzPoNs8vBN+/6tt1kmOBfaTgIaNUl9Mc8mG4wuIjvMEA3ktb8nAmuHxX0OSFP tZDQnNSaRED2rSPKXh1Dxa3NGOw9cg4x55Td6Vwq3UFarXTbuhpyQuRnuQe3b2sNhEbN PUVqO66SkcMLnGmC4zCRX5fvZMj3PtJRPn0nz1oWWpLm1jrNkQnuBAwJ3WwXAd7JWBOC nq1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WXK4+MIDry5NK9y+lmB0PCenZwFfuACmO+qMeWG3KfE=; b=PF73L+kQR0e7ZDEZZzt8ld5SKYskPcJ+83RMndLITsk6kzCZmkWcos/AmBYOMFil/6 IcdvMgDRdl751HMfwZLDeai3bFOq2hphN5xQFW10SLa0aUMqb6mM0t78SJ9PtS/DW1AX q+bvh1775NCHICqkSMoZZ1hRBkMoLftDFzTEqTRM3Ku18azxON2TwLwsa30nrAO9cemY 8+NUqubidEKUvmbj6lbCWxUreGRKxwsJrvkBML5ixJ4o3M+WHNF/yBiM9t3RN8hE77y9 ud8tziJvf0NouuopNf5V1mIfJu9NqmVd3tp2m+Ic9oyokNiTVq8AzkcuiiVSOVWJjwUb iUqw== X-Gm-Message-State: AE9vXwNG9HIsqFudN7MjAPkI+SkNHplvVwqMRwparTaNs5z4Ik/2SDUcGPzX8bm8Jwob8A== X-Received: by 10.98.64.93 with SMTP id n90mr32864822pfa.29.1473681715158; Mon, 12 Sep 2016 05:01:55 -0700 (PDT) Received: from [10.70.110.216] ([166.170.41.34]) by smtp.gmail.com with ESMTPSA id w63sm4236296pfk.43.2016.09.12.05.01.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Sep 2016 05:01:54 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854 Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (14A5346a) In-Reply-To: Date: Mon, 12 Sep 2016 13:01:48 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6E7490D9-BFC1-442A-A828-0841F2B831EF@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> To: Stig Venaas Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 12:01:59 -0000 --Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Stig, I'm traveling this week. I'll get you a reply over this coming weekend= .=20 Dino > On Sep 10, 2016, at 12:15 AM, Stig Venaas wrote: >=20 > Hi >=20 > On Thu, Sep 8, 2016 at 2:02 PM, Dino Farinacci wrote= : >>> Document: draft-ietf-lisp-lcaf-14.txt >>> Reviewer: Stig Venaas >>> Review Date: 2016-09-07 >>> IETF LC End Date: >>> Intended Status: Experimental >>=20 >> Thanks Stig for your comments. See responses below. As well as a new vers= ion -15 not submitted yet but for your quick review. Also find a lcaf-rfcdif= f.html file for easy diff viewing. >=20 > Thanks. I have some comments inline. >=20 >>> Summary: >>> I have some minor concerns about this document that I think should be >>> resolved before publication. >>>=20 >>> The draft is almost ready but there are several places where the text >>> is a bit unclear, >>=20 >> No problem. This document has had a long history and many opinions relate= d to it has come and gone but we tried to reflect everyone=E2=80=99s point o= f view. >>=20 >>> In section 1 I find this sentence a bit misleading since [AFI] doesn't >>> talk about the formatting. >>>=20 >>> Currently defined AFIs include IPv4 and IPv6 addresses, which are >>> formatted according to code-points assigned in [AFI] as follows: >>>=20 >>> Is the formatting shown here for AFI 1 and 2 defined in another >>> document? It would be good to have a reference. If it is introduced >>> in this document, then it should not be in the introduction. >>=20 >> No it is not shown in any document. All the AFI document says is that a 1= 6-bit AFI value of 1 means an IP address follows. That means 4 bytes of addr= ess. And 16 for IPv6 when AFI is 2. >>=20 >> As you can see the reference to the AFI document is at the end of the sen= tence. >>=20 >>> In section 2, first paragraph it says: >>> There is an address family currently defined for IPv4 or IPv6 >>> addresses. >>>=20 >>> It would be better to say that address families are defined for IPv4 >>> and IPv6 addresses. >>=20 >> Changed. >>=20 >>> In section 3 we have this paragraph: >>>=20 >>> The Address Family AFI definitions from [AFI] only allocate code- >>> points for the AFI value itself. The length of the address or entity >>> that follows is not defined and is implied based on conventional >>> experience. Where the LISP protocol uses LISP Canonical Addresses >>> specifically, the address length definitions will be in this >>> specification and take precedent over any other specification. >>>=20 >>> I'm not sure what conventional experience means. Please try to find a >>=20 >> Well like I said above, the AFI values defined in the AFI document are ju= st type values and there is no length defined. So =E2=80=9Cconventional wisd= om=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we know what f= ollows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >=20 > In theory there should be standards/documents specifying this for each > of the address types, and maybe could write that people should see the > respective standards or something. I don't know if this exists for all > the types though. >=20 >>> better way to say it. Regarding the last sentence, what if a you want >>> to define new LCAF encodings in the future? Is it good to say that this >>> specification takes precedent over any other? >>=20 >> LCAF encodings and definitions do not change the length of an AFI encoded= address. So I am not sure what you mean. >=20 > The last sentence says "Where the LISP protocol uses LISP Canonical > Addresses specifically, the address length definitions will be in this > specification and take precedent over any other specification.". What > if you in the future would like to write a separate specification that > defines additional LISP Canonical address formats? >=20 >>> In section 3 we have this paragraph: >>>=20 >>> Length: this 16-bit field is in units of bytes and covers all of the >>> LISP Canonical Address payload, starting and including the byte >>> after the Length field. So any LCAF encoded address will have a >>> minimum length of 8 bytes when the Length field is 0. The 8 bytes >>> include the AFI, Flags, Type, Reserved, and Length fields. When >>> the AFI is not next to encoded address in a control message, then >>> the encoded address will have a minimum length of 6 bytes when the >>> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >>> and Length fields. >>>=20 >>> Can you phrase this differently? First it says that any LCAF encoded >>=20 >> No not really. It is precise up to the sentence =E2=80=9CWhen the AFI is n= ot ..=E2=80=9D. >>=20 >>> address has a minimum length of 8, but then it goes on to say how it >>> sometimes is only 6. I understand what you're trying to say, but there >>> may be a better way of stating it. >>=20 >> This special case is for some LISP control-messages where the AFI is anot= her place in the message but the address is somewhere else. Rather than have= the AFI appear twice, the LCAF length needs to be different. >>=20 >> The length field always includes the entire contiguous set of LCAF bytes i= ncluding type, flags, length field, etc. >>=20 >> The language is precise and accurate. Let me know how you think stating w= hat I did in this comment response can be put in without writing a lot of te= xt about a special case. >=20 > The problem I see is that first you write "So any LCAF encoded address > will have a minimum length of 8 bytes when the Length field is 0." and > then you write "then the encoded address will have a minimum length of > 6 bytes when the Length field is 0." I understand what you mean, but I > feel this is a bit confusing. >=20 > Maybe you could say something like: >=20 > When including the AFI, an LCAF encoded address will have a minimum > length of 8 bytes when the Length field is 0. Or start by saying that > the minimal length is 6, and then say that it will then be 8 when the > AFI is included. >=20 >>> In section 3 it says: >>>=20 >>> Rsvd2: this 8-bit field is reserved for future use and MUST be >>> transmitted as 0 and ignored on receipt. >>>=20 >>> Some of the LCAFs specified in this document are using it though. Hence >>> you may need to change this text, and maybe not make it reserved. >>=20 >> I change to say the field is LCAF Type dependent and check the LCAF Type d= efinition to see what bits of this field is not reserved. >>=20 >>> The last sentence of section 3 is: >>>=20 >>> Therefore, when a locator-set has a mix of AFI records and >>> LCAF records, all LCAF records will appear after all the AFI records. >>>=20 >>> This is not necessarily true. Isn't it possible that one at some point >>> in the future might use other AFI records that have AFI > 16387? IANA >>> has assigned several values beyond 16387. >>=20 >> I will change to order must be in AFI value order. >>=20 >>> In 4.1 it says: >>> AFI =3D x: x can be any AFI value from [AFI]. >>>=20 >>> Is 16387 always or sometimes allowed? Might be good to clarify that. >>> This also applies >>> to all the other LCAF types with similar language. >>=20 >> Always. And since 16387 is in [AFI] and the sentence above says =E2=80=9C= can be any AFI value from [AFI]=E2=80=9D that implies it can be an LCAF AFI.= If I said =E2=80=9Cincluding the LCAF AFI, I would have to make this change= in a dozen places and would be repetitive. >=20 > I'll leave this to you, but one option could be to just mention it > here, and just say that it is true for other types as well. Or mention > somewhere before this in the draft that this is allowed. But you > already say "any AFI", so that should mean that this is allowed. >=20 >>> Section 4.4: >>>=20 >>> RTR RLOC Address: this is an encapsulation address used by an ITR or >>> PITR which resides behind a NAT device. This address is known to >>> have state in a NAT device so packets can flow from it to the LISP >>> ETR behind the NAT. There can be one or more NAT Tunnel Router >>> (NTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these >>> set of fields. The number of NTRs encoded is determined by the >>> LCAF length field. When there are no NTRs supplied, the NTR >>> fields can be omitted and reflected by the LCAF length field or an >>> AFI of 0 can be used to indicate zero NTRs encoded. >>>=20 >>> It is not quite clear to me if the NTR fields here are the RTR RLOC >>=20 >>> addresses. Does no NTR fields mean that there are no RTR RLOC addresses?= >>> If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length >>> 0), and that would have AFI 0? >>=20 >> Good catch. NTR was an old term and the NAT-traversal draft now uses the t= erm RTR. I will fix. >>=20 >>> Section 4.5 first paragraph: >>>=20 >>> Multicast group information can be published in the mapping database. >>> So a lookup on an group address EID can return a replication list of >>> RLOC group addresses or RLOC unicast addresses. >>>=20 >>> Can you have a mix of group addresses and unicast addresses? It's also >>=20 >> Yes, it just depends what address you put following the AFI value. >>=20 >>> not so clear from the format what source prefixes are. Are the source >>=20 >> I will state that when an (S,G) is encoded that is what the source addres= s field is used for. >>=20 >>> prefixes the same as the unicast RLOCs mentioned above? Can you have >>> both multiple source addresses and then multiple group addresses? Can >>> they be in arbitrarty order, or all sources followed by all groups? >>=20 >> As shown it is not a list. And if the AFI=3D0 precedes the Source/Subnet A= ddress field it means there is no source address encoded. >>=20 >>> It seems one will need to inspect the address itself to tell whether it >>> is a unicast or multicast address. This is probably fine. >>=20 >> Right. >>=20 >>> Section 4.6 >>> Add description of Rsvd3. >>>=20 >>> Section 4.7 >>> Add description of Rsvd3 and Rsvd4. >>=20 >> Changed. >>=20 >>> Section 4.10 >>> In this section there are several examples of using the AFI List Type, >>> but I miss a general definition. It appears that there can be a variable= >>> number of AFIs in the list. Any number > 0? It might be useful to have >>=20 >> Yes, a variable number. >=20 > How about adding a few lines of text to 4.10 saying that you can have > a variable number etc., explaining briefly what the general format is. > And then say that what follows are examples? >=20 >>> a length field associated with each AFI, or is it OK that parsing fails i= f >>> an AFI is unknown, so that the address length is not known? >>=20 >> Well each AFI has an implicit length per address entry and the LCAF Type l= ength has the total length. So why would we need to have yet another length a= nd complicate parsing even more? Please be aware (and I=E2=80=99m sure you a= re being a senior coder), that the more fields you add to parse, the more cr= oss-checking of field semantics and lengths have to be done. This really com= plicates the code and if part of the LCAF Type is parseable and others are n= ot, then you have a question about what you use and what you discard. >=20 > I guess I agree with you. Only issue I see is if you at some point > need an implementation to be able to parse past an unkown AFI, > basically not knowing the expected address length of the AFI. >=20 >>> Section 4.10.3 >>> Isn't it unusual to include the 0 termination? Since you know the >>> length it is not really needed. When parsing one will need to check >>> the length either way, what should one do it the string accidentally >>> is not 0-terminated? >>=20 >> Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate the= string. But the length field will imply it. However, I wrote the =E2=80=9Cd= istinguished-name=E2=80=9D draft to specify when AFI=3D17 is used (not only i= n a LCAF but by itself), how to terminate the string. I could include that r= eference, but that draft is not a working group document. >>=20 >> So please advise. >=20 > Currently it says: >=20 > Length value n: length in bytes AFI=3D17 field and the null-terminated > ASCII string (the last byte of 0 is included). >=20 > It might make sense to 0 terminate the DN in some cases, but at least > here we know the string length from the value of n, so I think it > would be better to drop it here. And as I mentioned, you cannot rely > on the 0 for parsing, to be on the safe side you would use n anyway. >=20 >>> Section 4.10.4 >>> I'm assuming that the recursion is more generic than this example? >>=20 >> Yes. >>=20 >>> It might be worth trying to explain the more generic concept and >>> format, and make sure that this is described as just an example. >>=20 >> I think that can raise too many combinations. It will be hard to explain w= hy someone will want to recurse a lot unless we have a well defined use-case= . The fact that an LCAF has an AFI value. It means that an LCAF can be encod= ed wherever an AFI value is allowed. >>=20 >> This section shows a practical example and not a general one that no one w= ould know how to use. >>=20 >>> Section 4.10.5 >>> This also appears to be just an example. >>=20 >> But a useful one that is already implemented in cisco code. >>=20 >>> Section 5.2 >>> Key Field Num: the number of fields (minus 1) the key can be broken >>> up into. The width of the fields are fixed length. So for a key >>> size of 8 bytes, with a Key Field Num of 4 allows 4 fields of 2 >>> bytes in length. Allowing for a reasonable number of 16 field >>> separators, valid values range from 0 to 15. >>>=20 >>> It says minus 1. Doesn't that mean that a Key Field Num of 4 indicates >>> 5 fields? >>=20 >> I fixed the description to be more clear. >>=20 >>> Key Wildcard Fields: describes which fields in the key are not used >>> as part of the key lookup. This wildcard encoding is a bitfield. >>> Each bit is a don't-care bit for a corresponding field in the key. >>> Bit 0 (the low-order bit) in this bitfield corresponds the first >>> field, right-justified in the key, bit 1 the second field, and so >>> on. When a bit is set in the bitfield it is a don't-care bit and >>>=20 >>> What does right-justified mean? Does it mean that the first field is the= >>> "low order" one? Basically at the end of the message? And the highest >>=20 >> Yes, I will make that more clear. >>=20 >>> order bit corresponds to the part of the key right after the wilcards? >>> I think this need to be explained better to ensure interoperability. >>>=20 >>> Key: the variable length key used to do a LISP Database Mapping >>> lookup. The length of the key is the value n (shown above) minus >>> 3. >>>=20 >>> Isn't it exactly the value n, since the length is n + 3? >>=20 >> Yes, you are right. Fixed. >>=20 >>> Section 5.4 >>> Length value n: length in bytes of fields that follow. >>> This is a bit confusing. I think 2+n is the length in bytes that follow >>> the lenght field. While n is the number of bytes after the JSON length. >>=20 >> The 2 is for the JSON length field, since it is a fixed field. The =E2=80= =9Cn=E2=80=9D is for the remaining variable length fields which include the J= SON-binary-text and the AFI address. I=E2=80=99ll make the Length descriptio= n reflect this. Thanks. >>=20 >>> Section 5.5 >>>=20 >>> It says "AFI =3D x" twice in the diagram. Based on this and the way it >>> is described it might seem that the two AFI values must be the same >>> value x, but they can differ, right? I this applies to several other >>> messages types as well. >>=20 >> I=E2=80=99ll change x to y in the second occurence and a description for e= ach. >>=20 >>> Section 7 >>> It looks like the table in the IANA considerations doesn't include all >>> the types defined in this document. >>=20 >> That was done intentionally. The ones that are experimental are not in th= is section 7 list because there is no use-case document for it yet. Maybe th= e chairs can explain this better than me. >=20 > I think it's still useful. If someone sees the type used, they can > look it up in the registry. It also helps avoid that someone perhaps > tries to reuse one of these types in new documents. If you really want > to use one of the code points for something else in the future, a new > document could always update the registry. >=20 > BTW, it also makes me wonder if it is worth reserving any LCAF types > for experiments. >=20 > Regards, > Stig >=20 >>> I'm happy to discuss my comments if needed, and also review any >>> updates to this draft. >>>=20 >>> Stig >>=20 >> Let me know about the response where I didn=E2=80=99t make any changes. >>=20 >> Thanks again, >> Dino/Dave/Job >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 --Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Stig, I'm traveling this week. I'll get you a reply over this coming week= end. 

Dino

On Sep 10, 2016, at 12:15 AM, Stig Ve= naas <stig@venaas.com> wrote:
Hi
<= br>On Thu, Sep 8, 2016 at 2:02 PM, Dino Farinacci <farinacci@gmail.com> wrote:
Document: draft-ietf-lisp-= lcaf-14.txt
Reviewer: Stig Venaas
<= /blockquote>
Review= Date: 2016-09-07
IETF LC End Date:
Inte= nded Status: Experimental

Th= anks Stig for your comments. See responses below. As well as a new version -= 15 not submitted yet but for your quick review. Also find a lcaf-rfcdiff.htm= l file for easy diff viewing.

= Thanks. I have some comments inline.

Summary:
I ha= ve some minor concerns about this document that I think should be
=
resolved before publication.

Th= e draft is almost ready but there are several places where the text
is a bit unclear,

N= o problem. This document has had a long history and many opinions related to= it has come and gone but we tried to reflect everyone=E2=80=99s point of vi= ew.

In section 1= I find this sentence a bit misleading since [AFI] doesn't
talk about the formatting.

 Curre= ntly defined AFIs include IPv4 and IPv6 addresses, which are
 formatted according to code-points assigned in [AFI] as follows:

Is the formatting shown here for AFI 1 a= nd 2 defined in another
document? It would be good to have= a reference. If it is introduced
in this document, then i= t should not be in the introduction.

No it is not shown in any document. All the AFI document says is th= at a 16-bit AFI value of 1 means an IP address follows. That means 4 bytes o= f address. And 16 for IPv6 when AFI is 2.

As you can see the reference to the AFI document is at the end of the sente= nce.

In section= 2, first paragraph it says:
 There is an address fa= mily currently defined for IPv4 or IPv6
=
 addresses.<= /span>

It would be better to say that address f= amilies are defined for IPv4
and IPv6 addresses.

Changed.

In section 3 we have this paragraph:=

<= blockquote type=3D"cite">  The Address Family AFI definitions fro= m [AFI] only allocate code-
 points for the AFI value= itself.  The length of the address or entity
 = that follows is not defined and is implied based on conventional
<= /blockquote>
 experience.  Where the LISP protocol uses LISP Canonical A= ddresses
 specifically, the address length definitio= ns will be in this
 specification and take precedent= over any other specification.

I'm not s= ure what conventional experience means. Please try to find a

Well like I said above, the AFI values defi= ned in the AFI document are just type values and there is no length defined.= So =E2=80=9Cconventional wisdom=E2=80=9D means that if a spec says an AFI v= alue 1 is IPv4, we know what follows is 4 bytes. Ditto for IPv6, MAC address= es, etc.

In theory there shoul= d be standards/documents specifying this for each
of the add= ress types, and maybe could write that people should see the
respective standards or something. I don't know if this exists for all
the types though.

better way to say it. Regarding the l= ast sentence, what if a you want
to define new LCAF encodi= ngs in the future? Is it good to say that this
specificati= on takes precedent over any other?

LCAF encodings and definitions do not change the length of an AFI enc= oded address. So I am not sure what you mean.
<= /span>
The last sentence says "Where the LISP protocol uses LISP Ca= nonical
Addresses specifically, the address length definitio= ns will be in this
specification and take precedent over any= other specification.". What
if you in the future would like= to write a separate specification that
defines additional L= ISP Canonical address formats?

In section 3 we have this paragraph:<= /span>

 Length:  this 16-bit field i= s in units of bytes and covers all of the
  &nb= sp; LISP Canonical Address payload, starting and including the byte
    after the Length field.  So any L= CAF encoded address will have a
    m= inimum length of 8 bytes when the Length field is 0.  The 8 bytes
    include the AFI, Flags, Type, Reserved= , and Length fields.  When
    t= he AFI is not next to encoded address in a control message, then
<= /blockquote>
    the encoded address will have a minimum leng= th of 6 bytes when the
    Length field= is 0.  The 6 bytes include the Flags, Type, Reserved,
    and Length fields.

<= /blockquote>
Can you phrase this differently? First it says that any LCAF encoded<= /span>
<= br>
No not really. It is precise= up to the sentence =E2=80=9CWhen the AFI is not ..=E2=80=9D.

address has a minimum length o= f 8, but then it goes on to say how it
<= blockquote type=3D"cite">
sometimes is only 6= . I understand what you're trying to say, but there
<= /blockquote>
may be= a better way of stating it.

This special case is for some LISP control-messages where the AFI is anothe= r place in the message but the address is somewhere else. Rather than have t= he AFI appear twice, the LCAF length needs to be different.

The length field always includes the entire contiguous se= t of LCAF bytes including type, flags, length field, etc.

The language is precise and accurate. Let me know how you t= hink stating what I did in this comment response can be put in without writi= ng a lot of text about a special case.
<= br>The problem I see is that first you write "So any LCAF encoded addr= ess
will have a minimum length of 8 bytes when the Length fi= eld is 0." and
then you write "then the encoded address will= have a minimum length of
6 bytes when the Length field is 0= ." I understand what you mean, but I
feel this is a bit conf= using.

Maybe you could say something like:<= /span>

When including the AFI, an LCAF encoded add= ress will have a minimum
length of 8 bytes when the Length f= ield is 0. Or start by saying that
the minimal length is 6, a= nd then say that it will then be 8 when the
AFI is included.=

In section 3 it says:

 = Rsvd2:  this 8-bit field is reserved for future use and MUST be<= br>
    transmitted as 0 and ignored on receipt.=

Some of the LCAFs specified in this do= cument are using it though. Hence
you may need to change t= his text, and maybe not make it reserved.

I change to say the field is LCAF Type dependent and check the L= CAF Type definition to see what bits of this field is not reserved.

The last sentence of se= ction 3 is:

 Therefore, when a lo= cator-set has a mix of AFI records and
<= blockquote type=3D"cite">
 LCAF records= , all LCAF records will appear after all the AFI records.
=
This is not necessarily true. Isn't it possible that one a= t some point
<= blockquote type=3D"cite">in the future might use other AFI records tha= t have AFI > 16387? IANA
has assigned several values bey= ond 16387.

I will change to o= rder must be in AFI value order.

In 4.1 it says:
 AFI =3D x:  = x can be any AFI value from [AFI].

Is 1= 6387 always or sometimes allowed? Might be good to clarify that.
<= /blockquote>
This also applies
to all the other LCAF types with s= imilar language.

Always. And= since 16387 is in [AFI] and the sentence above says =E2=80=9Ccan be any AFI= value from [AFI]=E2=80=9D that implies it can be an LCAF AFI. If I said =E2= =80=9Cincluding the LCAF AFI, I would have to make this change in a dozen pl= aces and would be repetitive.

= I'll leave this to you, but one option could be to just mention ithere, and just say that it is true for other types as well. Or mentio= n
somewhere before this in the draft that this is allowed. B= ut you
already say "any AFI", so that should mean that this i= s allowed.

Section 4.4:

 = RTR RLOC Address:  this is an encapsulation address used by an ITR or
    PITR which resides behind a NAT de= vice.  This address is known to
   &n= bsp;have state in a NAT device so packets can flow from it to the LISP
    ETR behind the NAT.  There can be= one or more NAT Tunnel Router
    (N= TR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these
<= /blockquote>
    set of fields.  The number of NTRs enco= ded is determined by the
    LCAF len= gth field.  When there are no NTRs supplied, the NTR
=     fields can be omitted and reflected by the LCAF len= gth field or an
    AFI of 0 can be u= sed to indicate zero NTRs encoded.

It i= s not quite clear to me if the NTR fields here are the RTR RLOC

addresses. Doe= s no NTR fields mean that there are no RTR RLOC addresses?
If AFI 0 is used, would there be exactly 1 RTR RLOC address (of length
0), and that would have AFI 0?

Good catch. NTR was an old term and the NAT-traversal draft n= ow uses the term RTR. I will fix.

Section 4.5 first paragraph:
 Multicast group information can be published in the mapping d= atabase.
 So a lookup on an group address EID can re= turn a replication list of
 RLOC group addresses or R= LOC unicast addresses.

=
Can you have a mix= of group addresses and unicast addresses? It's also
=

Yes, it just depends what address you put following= the AFI value.

not so clear from the format what source prefixes are. Are the source

I will state that when an (S,G) i= s encoded that is what the source address field is used for.

prefixes the same as the unicas= t RLOCs mentioned above? Can you have
both multiple source= addresses and then multiple group addresses? Can
they be i= n arbitrarty order, or all sources followed by all groups?

<= blockquote type=3D"cite">As shown it is not a list. And if the AFI=3D0= precedes the Source/Subnet Address field it means there is no source addres= s encoded.
It s= eems one will need to inspect the address itself to tell whether it
is a unicast or multicast address. This is probably fine.

Right.

=
Section 4.6
Add descriptio= n of Rsvd3.

Section 4.7
Add description of Rsvd3 and Rsvd4.
<= blockquote type=3D"cite">
Changed.
<= /span>
<= span>Section 4.10
In this section there are several exampl= es of using the AFI List Type,
but I miss a general defini= tion. It appears that there can be a variable
number of AFI= s in the list. Any number > 0? It might be useful to have

Yes, a variable number.

How about adding a few lines of text to 4.10 sayi= ng that you can have
a variable number etc., explaining brie= fly what the general format is.
And then say that what follo= ws are examples?

a length field associated with each AFI, or is it O= K that parsing fails if
an AFI is unknown, so that the add= ress length is not known?

We= ll each AFI has an implicit length per address entry and the LCAF Type lengt= h has the total length. So why would we need to have yet another length and c= omplicate parsing even more? Please be aware (and I=E2=80=99m sure you are b= eing a senior coder), that the more fields you add to parse, the more cross-= checking of field semantics and lengths have to be done. This really complic= ates the code and if part of the LCAF Type is parseable and others are not, t= hen you have a question about what you use and what you discard.
<= /blockquote>
I guess I agree with you. Only issue I se= e is if you at some point
need an implementation to be able t= o parse past an unkown AFI,
basically not knowing the expect= ed address length of the AFI.

Section 4.10.3
Isn'= t it unusual to include the 0 termination? Since you know the
length it is not really needed. When parsing one will need to check
the length either way, what should one do it the string acciden= tally
is not 0-terminated?

Well the AFI definition in [AFI] doesn=E2=80=99t say how to= terminate the string. But the length field will imply it. However, I wrote t= he =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is us= ed (not only in a LCAF but by itself), how to terminate the string. I could i= nclude that reference, but that draft is not a working group document.

So please advise.

Currently it says:

 = ; Length value n:  length in bytes AFI=3D17 field and the null-ter= minated
     ASCII string (the las= t byte of 0 is included).

It might make sen= se to 0 terminate the DN in some cases, but at least
here we= know the string length from the value of n, so I think it
w= ould be better to drop it here. And as I mentioned, you cannot relyon the 0 for parsing, to be on the safe side you would use n anyway.=

Section 4.10.4
I'm assuming that the recursion i= s more generic than this example?

= Yes.
It m= ight be worth trying to explain the more generic concept and
format, and make sure that this is described as just an example.

I think that can raise too many comb= inations. It will be hard to explain why someone will want to recurse a lot u= nless we have a well defined use-case. The fact that an LCAF has an AFI valu= e. It means that an LCAF can be encoded wherever an AFI value is allowed.

This section shows a practical example and n= ot a general one that no one would know how to use.
<= blockquote type=3D"cite">
Section 4.10.5
<= /blockquote>
This a= lso appears to be just an example.

But a useful one that is already implemented in cisco code.

Section 5.2
=  Key Field Num:  the number of fields (minus 1) the key can= be broken
    up into.  The wid= th of the fields are fixed length.  So for a key
&nb= sp;   size of 8 bytes, with a Key Field Num of 4 allows 4 fie= lds of 2
    bytes in length.  A= llowing for a reasonable number of 16 field
  &= nbsp; separators, valid values range from 0 to 15.

It says minus 1. Doesn't that mean that a Key Field Num of 4= indicates
5 fields?
<= blockquote type=3D"cite">
I fixed the description to be more clear.
=

 Key Wildcard Fields:  desc= ribes which fields in the key are not used
  &n= bsp; as part of the key lookup.  This wildcard encoding is a bitfi= eld.
    Each bit is a don't-care bit= for a corresponding field in the key.
<= blockquote type=3D"cite">
   =  Bit 0 (the low-order bit) in this bitfield corresponds the first
    field, right-justified in the key, bit= 1 the second field, and so
    on. &n= bsp;When a bit is set in the bitfield it is a don't-care bit and
<= /blockquote>

What does right-justified mean? Does it mean that t= he first field is the
"low order" one? Basically at the end= of the message? And the highest

<= span>Yes, I will make that more clear.

order bit corresponds to the part of the key right a= fter the wilcards?
I think this need to be explained bette= r to ensure interoperability.

 Ke= y:  the variable length key used to do a LISP Database Mapping
    lookup.  The length of the key is th= e value n (shown above) minus
    3.<= /span>

Isn't it exactly the value n, since the= length is n + 3?

Yes, you a= re right. Fixed.

Section 5.4
=
 Length value n:  length in bytes= of fields that follow.
This is a bit confusing. I think 2= +n is the length in bytes that follow
the lenght field. Wh= ile n is the number of bytes after the JSON length.
<= /blockquote>

The 2 is for the JSON length field, since it is a fi= xed field. The =E2=80=9Cn=E2=80=9D is for the remaining variable length fiel= ds which include the JSON-binary-text and the AFI address. I=E2=80=99ll make= the Length description reflect this. Thanks.

<= blockquote type=3D"cite">Section 5.5

It says "AFI =3D x" twice in the diagram. Based on this and the way it
is described it might seem that the two AFI values must be t= he same
value x, but they can differ, right? I this applie= s to several other
messages types as well.

I=E2=80=99ll change x to y in the second oc= curence and a description for each.

Section 7
It looks like the table in th= e IANA considerations doesn't include all
the types define= d in this document.

That was= done intentionally. The ones that are experimental are not in this section 7= list because there is no use-case document for it yet. Maybe the chairs can= explain this better than me.

= I think it's still useful. If someone sees the type used, they canlook it up in the registry. It also helps avoid that someone perhaps<= /span>
tries to reuse one of these types in new documents. If you r= eally want
to use one of the code points for something else i= n the future, a new
document could always update the registr= y.

BTW, it also makes me wonder if it is wo= rth reserving any LCAF types
for experiments.

Regards,
Stig

=
I'm happy to discu= ss my comments if needed, and also review any
updates to t= his draft.

Stig
=

Let me know about the response where I didn=E2=80=99= t make any changes.
<= /span>
Thanks again,<= br>
Dino/Dave/Job









= = --Apple-Mail-E20CC696-ECBE-4FFE-854A-234B01640854-- From nobody Mon Sep 12 05:05:57 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F1C12B259; Mon, 12 Sep 2016 05:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZxx9gSw-MMo; Mon, 12 Sep 2016 05:05:50 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E6912B211; Mon, 12 Sep 2016 05:05:47 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id 16so111004882vko.2; Mon, 12 Sep 2016 05:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=TMh6gJbfM53im7oquHAFVZUMGwdfqMAqywT1fv28nVo=; b=wBkYgBdROKbgoaBjUAcTOBLKsrwy9klyCHHkWnIFiJBZxGSUwTviIpJYX7ANIciVUv eGWAbWS2eFi5CI3t2xMqqyVNDW5SJD0mK7sneh2dOSW4034smArveDHoSCMIze3lR6tb dnI6lbDYqBF1k3WMLjKqCFoI9Bmsr4n1OIdZsAcQAe8raYeAhFK0Ov+juV2PcZehgQak nhXgpI3/BBnxR27bRj06Uz7yU23dOb4D1iMIEFQkqCJqzwQb8NzvSIAkuLv43PzxeA0u uhMTYsticJYnpC6lO2KsUw8MbNvODsk3AgMmgBTBvrWNtBf+c86hDhWkECmvZcZxoZ8W uvYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=TMh6gJbfM53im7oquHAFVZUMGwdfqMAqywT1fv28nVo=; b=f2xR6XXDyPcmKyRd4hEdU8jZM+b6JnFcoLwhYXK+ZKvqoSs/49ufB/ohGJdifNL6RE zuJmHnlSYt8jkzbDqs9LLUldSw2+ZDPpEC408+wk77yeJ4okOj92GgKHSIhzSiRci35W 8xyIqy4+pgVt2cNr5K7c9+qAoV90cXawC84eWOPLG1nSy8OhkbStN8na1EWTDthj9oFh s9YSgH5Xs1945xAsyAUwszkkinyKtAii/YpWBWvwDg7J92t6SlRu0OFUDD2C+jcnT4Vs r+Q/qmk6oUq0rLHm52gyMEXOa1Y2cc8DUEsF3rBTiaA6y6J9IlY7pFxwilbtgKjHtNQp k8Qw== X-Gm-Message-State: AE9vXwNxGsxE/hXJfvKIQTQC+ql1bHhIE2eLSHbROmdorgw8k3qbZp7Sddr1ZSR8YDD7klBnPNlVT2paCRhn/Q== X-Received: by 10.31.16.86 with SMTP id g83mr12162336vki.34.1473681946262; Mon, 12 Sep 2016 05:05:46 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.176.1.113 with HTTP; Mon, 12 Sep 2016 05:05:25 -0700 (PDT) From: Emmanuel Baccelli Date: Mon, 12 Sep 2016 14:05:25 +0200 X-Google-Sender-Auth: cXrcQ42mhiVuwdJLwAd0W2YRsIw Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a11432270eb7c47053c4e50de Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-idr-bgp-gr-notification.all@ietf.org, idr@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-gr-notification-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 12:05:53 -0000 --001a11432270eb7c47053c4e50de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-idr-bgp-gr-notification-07 Reviewer: Emmanuel Baccelli Review Date: Sept. 12th 2016 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document is clearly written and easy to understand. I am not a BGP specialist, and in particular I was not familiar with the details of BGP Graceful restart before I have reviewed, so I had to go back and read RFC4724. It may mean that my review is not sufficiently in-depth, or that the nits I point out and my editorial suggestions may be too pedantic. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: Nits and minor suggestions below can be considered, aiming to improve readability. Working group indication: - indicate IDR working group at the top of the document (for now it says "Network working group") Abstract: - for clarity, append at the end of last sentence "and for force a full reset"? Section 2 - in restart flags, for completeness, recall that R flag is specified in RFC4724 and what it indicates. - recall that reserved/unspecified fields must be zeroed (and ignored)? - spell out acronyms AFI and SAFI (in terminology section, as coming from RFC4724?) before first use in the document - in Address family flags: remove "deprecated" specification text Section 4: - "When a BGP speaker resets its session due to a HOLDTIME expiry, it should generate..." =3D> s/should/SHOULD Section 4.1: - the last paragraph of section 4.2 of RFC4724 states that support for the stale route retain timer is a MAY. It seems appropriate to specify upfront that this timer is now a MUST? - "This supersedes the "consecutive restarts" requirement of [RFC4724] S. 4.2." =3D> for convenience indicate which paragraph (3rd paragraph) of RFC4724 S= . 4.2. --001a11432270eb7c47053c4e50de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.or= g/area/rtg/trac/wiki/RtgDir

Although these com= ments 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 y= ou receive, and strive to resolve them through discussion or by updating th= e draft.

Document: draft-ietf-idr-bgp-gr-notificat= ion-07
Reviewer: Emmanuel Baccelli
Review Date: Sept. 1= 2th 2016=C2=A0
Intended Status: Standards Track

Summary:=C2=A0

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

Comments:

This d= ocument is clearly written and easy to understand. =C2=A0
I am no= t a BGP specialist, and in particular I was not familiar with the details o= f BGP Graceful restart before I have reviewed, so I had to go back and read= RFC4724.=C2=A0
It may mean that my review is not sufficiently in= -depth, or that the nits I point out and my editorial suggestions may be to= o pedantic.


Major Issues:
No major issues found.


Minor Issue= s:
No minor issues found.


Nits:

Nits and minor suggestions below can be con= sidered, aiming to improve readability.

Working gr= oup indication:
=C2=A0- indicate IDR working group at the top of = the document (for now it says "Network working group")
=
Abstract:
=C2=A0- for clarity, append at the end o= f last sentence "and for force a full reset"?
=C2=A0
Section 2
=C2=A0- in restart flags, for completeness, rec= all that R flag is specified in RFC4724 and what it indicates.
= =C2=A0- recall that reserved/unspecified fields must be zeroed (and ignored= )?
=C2=A0- spell out acronyms AFI and SAFI (in terminology sectio= n, as coming from RFC4724?) before first use in the document
=C2= =A0- in Address family flags: remove "deprecated" specification t= ext
=C2=A0
=C2=A0
=C2=A0Section 4:
= =C2=A0- "When a BGP speaker resets its session due to a HOLDTIME expir= y, it should generate..."
=C2=A0 =3D> s/should/SHOULD=C2= =A0
=C2=A0 =C2=A0
=C2=A0 =C2=A0
=C2=A0Section= 4.1:
=C2=A0- the last paragraph of section 4.2 of RFC4724 states= that support for the stale route retain timer is a MAY.=C2=A0
= =C2=A0It seems appropriate to specify upfront that this timer is now a MUST= ?

=C2=A0- "This supersedes the "consecut= ive restarts" requirement of [RFC4724] S. 4.2."=C2=A0
= =C2=A0=3D> for convenience indicate which paragraph (3rd paragraph) of R= FC4724 S. 4.2.
--001a11432270eb7c47053c4e50de-- From nobody Mon Sep 12 23:19:50 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95512B1F8; Mon, 12 Sep 2016 23:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 7j-Bh7IEV3Ld; Mon, 12 Sep 2016 23:19:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5438012B17E; Mon, 12 Sep 2016 23:19:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRE41023; Tue, 13 Sep 2016 06:19:42 +0000 (GMT) Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 13 Sep 2016 07:19:41 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.52]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Tue, 13 Sep 2016 14:19:33 +0800 From: "Zhangxian (Xian)" To: Tomonori Takeda , "'rtg-ads@ietf.org'" Thread-Topic: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt Thread-Index: AdIKqDg5BThlaDp0Suq7kh+dmeZr1AC2oRmA Date: Tue, 13 Sep 2016 06:19:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.139.68] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57D79A7E.00AC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5a3b6ba6ec6a384224e41a5f910136c Archived-At: Cc: "'rtg-dir@ietf.org'" , Ina Minei , "'pce@ietf.org'" , Dhruv Dhody , "'draft-ietf-pce-stateful-pce-app@ietf.org'" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 06:19:49 -0000 SGksIFRvbW9ub3JpIFRha2VkYSwgDQoNCiAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBk ZXRhaWxlZCByZXZpZXcuIFdpdGggcmVnYXJkIHRvIHRoZSB0d28gbWlub3IgaXNzdWVzIHlvdSBy YWlzZWQsIHBsZWFzZSBzZWUgaW5saW5lIG1hcmtlZCB3aXRoIDxYSUFOPjogDQoNCi0tLS0t08q8 /tStvP4tLS0tLQ0Kt6K8/sjLOiBUb21vbm9yaSBUYWtlZGEgW21haWx0bzp0b21vbm9yaS50YWtl ZGFAbnR0LmNvbV0gDQq3osvNyrG85DogMjAxNsTqOdTCOcjVIDIyOjQ2DQrK1bz+yMs6ICdydGct YWRzQGlldGYub3JnJw0Ks63LzTogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1wY2Ut c3RhdGVmdWwtcGNlLWFwcEBpZXRmLm9yZyc7ICdwY2VAaWV0Zi5vcmcnDQrW98ziOiBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtYXBwLTA2LnR4dA0KDQpIZWxsbywN Cg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3 ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmll dyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJv dWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVj aWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBh cmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUg aGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJ RVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0K DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcC0wNi50eHQNClJldmll d2VyOiBUb21vbm9yaSBUYWtlZGENClJldmlldyBEYXRlOiBTZXB0ZW1iZXIgOXRoLCAyMDE2DQpJ RVRGIExDIEVuZCBEYXRlOiBOb3Qga25vd24NCkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25h bA0KDQpTdW1tYXJ5OiANCg0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBk b2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlv bi4gDQoNCkNvbW1lbnRzOiANCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYXBwbGljYWJpbGl0 eSBvZiBhIHN0YXRlZnVsIFBDRSwgYXMgd2VsbCBhcyBnZW5lcmFsIGNvbnNpZGVyYXRpb25zIGZv ciBkZXBsb3ltZW50LiBUaGUgZG9jdW1lbnQgaXMgd2VsbCBvcmdhbml6ZWQgYW5kIGVhc3kgdG8g cmVhZC4gSG93ZXZlciwgdGhlcmUgYXJlIHNvbWUgbWlub3IgcG9pbnRzIHdoaWNoIEkgdGhpbmsg c2hvdWxkIGJlIGNsYXJpZmllZCBmb3IgY29tcGxldGVuZXNzIGFuZCBlYXNpbmVzcyB0byByZWFk eS4NCg0KTWFqb3IgSXNzdWVzOiANCg0KTm9uZQ0KDQpNaW5vciBJc3N1ZXM6IA0KDQoxKSBJbiBw YWdlIDUsIHNlY3Rpb24gNC4xLCBtdWx0aS1QQ0UgZGVwbG95bWVudHMgYXJlIGRlc2NyaWJlZC4g SXQgc2F5cywgIlJlZ2FyZGxlc3Mgb2YgdGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgUENFcywgYW4g TFNQIGlzIG9ubHkgZGVsZWdhdGVkIHRvIG9uZSBvZiB0aGUgUENFcyBhdCBhbnkgZ2l2ZW4gcG9p bnQgaW4gdGltZS4iIElzIHRoaXMgZGVzY3JpYmVkL2RlZmluZWQgaW4gc29tZSBvdGhlciBkb2N1 bWVudCwgb3IgaW4gdGhpcyBkb2N1bWVudD8gSW4gdGhlIGZpcnN0IGNhc2UsIHBsZWFzZSBpbmRp Y2F0ZSBhIHJlZmVyZW5jZS4gSW4gdGhlIGxhdHRlciBjYXNlLCBJIHdvdWxkIGxpa2UgdG8gc2Vl IG1vcmUgY2xhcmlmaWNhdGlvbiBhbmQgcmVhc29uaW5nLg0KIDxYSUFOPjogV2UgYWN0dWFsbHkg dGFrZSB0aGlzIGFzIGEgY29tbW9ubHkgYWdyZWVkIGFzc3VtcHRpb24gYW5kIGl0IGlzIGFsc28g c3RhdGVkIGluIDwgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcGNlLXN0 YXRlZnVsLXBjZS0xNj4uIEFzIHNwZWNpZmllZCBpbiB0aGF0IGRyYWZ0IFNlY3Rpb24gMiwgZGVs ZWdhdGlvbiBtZWFucyB0aGF0IHdob2V2ZXIgYWNjZXB0cyB0aGlzIGRlbGVnYXRpb24gd2lsbCBi ZSBhYmxlIHRvIGNoYW5nZSBpdHMgYXR0cmlidXRlcy4gU28sIGFsbG93aW5nIG1vcmUgdGhhbiBv bmUgZW50aXR5IHRvIGFjY2VwdCB0aGUgZGVsZWdhdGlvbiBhdCBhIGdpdmVuIHRpbWUgKE9SIHJl cXVlc3RpbmcgY29udHJvbCBvZiBhIExTUCB0byBtb3JlIHRoYW4gb25lIFBDRXMpIGlzIG5vdCBn b2luZyB0byB3b3JrLiBEb2VzIGFkZGluZyBhIGV4cGxpY2l0IHJlZmVyZW5jZSB0byB0aGUgZHJh ZnQgd2hlcmUgZGVsZWdhdGlvbiBpcyBkZWZpbmVkIHdvcmsgZm9yIHlvdT8NCg0KMikgSW4gcGFn ZSAxMiwgc2VjdGlvbiA1LjEuNCwgcHJlZGljdGFiaWxpdHkgaXMgZGVzY3JpYmVkIGFzIGFuIGFw cGxpY2F0aW9uLiBJdCBzYXlzICJBIHN0YXRlZnVsIFBDRSBjYW4gc29sdmUgdGhpcyB0aHJvdWdo IGNvbnRyb2wgb3ZlciBMU1Agb3JkZXJpbmcuIiwgYnV0IEkgYW0gbm90IHN1cmUgaG93IHN0YXRl ZnVsIFBDRSBzb2x2ZXMgdGhpcyBzY2VuYXJpby4gSXMgaXQgcG9zc2libGUgZXZlbiBpZiBjb21w dXRhdGlvbiByZXF1ZXN0cyBjb21lIGluIGEgdGltZSBzZXJpZXM/IE9yIGlzIGl0IGFzc3VtZWQg dGhhdCBhIHN0YXRlZnVsIFBDRSBpcyB1c2VkIGluIHN1Y2ggYSB3YXkgdGhhdCBjb21wdXRhdGlv biByZXF1ZXN0cyBkbyBub3QgY29tZSBpbiBhIHRpbWUgc2VyaWVzPyAoRm9yIGV4YW1wbGUsIGlu IGEgZmFpbHVyZSBzY2VuYXJpbywgTFNQIHJlLWNvbXB1dGF0aW9uIGlzIG5vdCB0cmlnZ2VyZWQg YnkgUENDIHJlcXVlc3RpbmcgcGF0aCBjb21wdXRhdGlvbiwgYnV0IGJ5IGxpbmsgZmFpbHVyZT8p DQoNCjxYSUFOPjogSSB0aGluayB5b3UgY2FwdHVyZWQgdGhlIGludGVudGlvbiB3ZWxsIGluIHRo ZSAybmQgY2FzZSB5b3VyIGVsYWJvcmF0ZWQuIFRoaXMgdXNlIGNhc2UgYXNzdW1lcyB0aGUgdXNl IG9mIGFuIGFjdGl2ZSBzdGF0ZWZ1bCBQQ0Ugd2hpY2ggY2FuIHRyaWdnZXIgcmUtY29tcHV0YXRp b24gYmFzZWQgb24gdHJpZ2dlciBzdWNoIGFzIGJ1dCBub3QgbGltaXRlZCBmYWlsdXJlcywgcmF0 aGVyIHRoYW4gYmFzZWQgb24gdW5kZXRlcm1pbmVkIHNlcXVlbnRpYWwgY29tcHV0YXRpb24gcmVx dWVzdHMuIEhvdyBhYm91dCBleHBhbmRpbmcgdGhlIGxhc3Qgc2VudGVuY2UgYXMgdGhlIGZvbGxv d2luZz8NCg0KT0xEOiANCkEgc3RhdGVmdWwgUENFIGNhbiBzb2x2ZSB0aGlzIHRocm91Z2ggY29u dHJvbCBvdmVyIExTUCBvcmRlcmluZy4NCk5FVzogDQpBbiBhY3RpdmUgc3RhdGVmdWwgUENFIGNh biBzb2x2ZSB0aGlzIHRocm91Z2ggY29udHJvbCBvdmVyIExTUCBvcmRlcmluZy4gQmFzZWQgb24g dHJpZ2dlcnMgc3VjaCBhcyBhIGZhaWx1cmUgb3IgYW4gb3B0aW1pemF0aW9uIHRyaWdnZXIsIHRo ZSBQQ0UgY2FuIG9yZGVyIHRoZSBjb21wdXRhdGlvbnMgYW5kIHBhdGggc2V0dXAgaW4gYSBkZXRl cm1pbmlzdGljIHdheS4gDQoNClJlZ2FyZHMsDQpYaWFuIChvbiBiZWhhbGYgb2YgYWxsIGF1dGhv cnMvY29udHJpYnV0b3JzKQ0KDQpOaXRzOg0KDQpOb25lDQoNClRoYW5rcywNClRvbW9ub3JpIFRh a2VkYQ0K From nobody Tue Sep 13 03:08:47 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38A012B2D2 for ; Tue, 13 Sep 2016 03:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-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 fpoUSFcF-cIg for ; Tue, 13 Sep 2016 03:08:37 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FB412B2D4 for ; Tue, 13 Sep 2016 03:08:30 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id 1so191687466wmz.1 for ; Tue, 13 Sep 2016 03:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cUozONWHxZOmPIq3yNqXNDMMFryCFAJE17GQAkK9vOU=; b=zuYUPJrx8udlG2fGTbff6gTxtdo1SPz0fKjADecpl5S+kTJ6+EKmMXftlXwwWT+HQh xo5JecTo9CL6rC6lwrIQBUlrq5MrbteLfh4EEwK6+AmOatXa/OUFE2V36eJYN8Wm9LsQ L/Ew6ivIvEdYjopFIWdqD0Ub85uGgre5AW5azJ/WqiPAzYkOK/OaA8+iH1l53bCR38i9 QZqX5yrKStVhagHvkbjFCxdEM4A0/jXBWwhhS6oRPmkPzXq86pAuw+R4pZVqi+D7nf/r Qh1XhjY8uduCJWiUAaEs56OeWtd2b8zcF6+vpQsFdWvR+cHfgFNA86gSqxrZNLeWMWoO IGtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cUozONWHxZOmPIq3yNqXNDMMFryCFAJE17GQAkK9vOU=; b=Gou4lCibCv1jEzL1M+tbrrMF3vkUvdnybKw1qwob4ORF9nlg+eTMFMZ9aprW5G8LDG 94JXJ80yhiGAcKSD0YewMi9ZyRxqBpk4ZxQlYKtc/WbcLq4NrmVVylisIX/eBUz9e1L+ JJnjhfEEo0gsML1Qdl+VgpFJ5bJk3UiAavRcBwNw5lahRcSp9Pn5OBMwJhMT30aV7Elu Cnde8lukE28Ec5ul9sw77HrrGKBMkP3HQud46IY4HZ8jYNeUzI0dIbbnZiZwcVqGVdnU 2lq3Cir1afjS/IZf+OEBMLHUTb3J4+McPGwGM+GlUe/gLWNOHmYIahibCVVeNgeQLh0j 1OvQ== X-Gm-Message-State: AE9vXwM2k9gVXZZQwWfFTVz12NnNVgH/clpT6IeX8sN4JPTjKX+yndCpGi/cjCaLcgbK+g== X-Received: by 10.28.14.144 with SMTP id 138mr15835218wmo.96.1473761309174; Tue, 13 Sep 2016 03:08:29 -0700 (PDT) Received: from ?IPv6:2a01:e35:1381:3430:5d2a:dbd5:c77c:ac65? ([2a01:e35:1381:3430:5d2a:dbd5:c77c:ac65]) by smtp.gmail.com with ESMTPSA id m5sm28735894wmd.1.2016.09.13.03.08.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Sep 2016 03:08:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luigi Iannone In-Reply-To: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> Date: Tue, 13 Sep 2016 12:08:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, Stig Venaas , LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org, rtg-dir@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 10:08:39 -0000 Hi Stig, thanks for the review. Just a quick comment on one of the last point you raised: > On 08 Sep 2016, at 23:02, Dino Farinacci wrote: >=20 [snip] >=20 >> Section 7 >> It looks like the table in the IANA considerations doesn't include = all >> the types defined in this document. >=20 > That was done intentionally. The ones that are experimental are not in = this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. >=20 AFAIR the rationale was that since these types are experimental = proposals, with no (or at least not yet) detailed use-case, there is no = need to allocate these values now. If new documents will use them, than those documents will require = allocation in their IANA section. ciao L. =20 >> I'm happy to discuss my comments if needed, and also review any >> updates to this draft. >>=20 >> Stig >=20 > Let me know about the response where I didn=E2=80=99t make any = changes. >=20 > Thanks again, > Dino/Dave/Job >=20 > >=20 > From nobody Tue Sep 13 04:29:40 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C6512B31F; Tue, 13 Sep 2016 04:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, 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 cbBqhv_Pg8Oq; Tue, 13 Sep 2016 04:29:35 -0700 (PDT) Received: from mgw020.noc.ntt.com (mgw020.noc.ntt.com [210.160.55.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA3412B31D; Tue, 13 Sep 2016 04:29:33 -0700 (PDT) Received: from c0044i0.coe.ntt.com (c0044i0.nc.agilit-hosting.com [10.18.161.13]) by mgw020.noc.ntt.com (NTT Com MailSV) with ESMTP id F1CB8446181A; Tue, 13 Sep 2016 20:29:32 +0900 (JST) Received: from C0038I0.coe.ntt.com (10.18.160.42) by c0044i0.coe.ntt.com (10.18.161.13) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 13 Sep 2016 20:29:32 +0900 Received: from C0561I0.coe.ntt.com ([169.254.1.161]) by C0038I0.coe.ntt.com ([10.18.160.42]) with mapi id 14.03.0181.006; Tue, 13 Sep 2016 20:29:32 +0900 From: Tomonori Takeda To: "'Zhangxian (Xian)'" , "'rtg-ads@ietf.org'" Thread-Topic: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt Thread-Index: AdIKqDg5BThlaDp0Suq7kh+dmeZr1AC2oRmAAAuUukA= Date: Tue, 13 Sep 2016 11:29:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ccmail-original-to: zhang.xian@huawei.com, rtg-ads@ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, inaminei@google.com, pce@ietf.org, dhruv.dhody@huawei.com, draft-ietf-pce-stateful-pce-app@ietf.org x-originating-ip: [10.25.148.95] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'rtg-dir@ietf.org'" , Ina Minei , "'pce@ietf.org'" , Dhruv Dhody , "'draft-ietf-pce-stateful-pce-app@ietf.org'" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 11:29:38 -0000 SGkgWGlhbg0KDQpUaGFua3MuDQoNCjxYSUFOPjogV2UgYWN0dWFsbHkgdGFrZSB0aGlzIGFzIGEg Y29tbW9ubHkgYWdyZWVkIGFzc3VtcHRpb24gYW5kIGl0IGlzIGFsc28gc3RhdGVkIGluIDwgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS0xNj4u IEFzIHNwZWNpZmllZCBpbiB0aGF0IGRyYWZ0IFNlY3Rpb24gMiwgZGVsZWdhdGlvbiBtZWFucyB0 aGF0IHdob2V2ZXIgYWNjZXB0cyB0aGlzIGRlbGVnYXRpb24gd2lsbCBiZSBhYmxlIHRvIGNoYW5n ZSBpdHMgYXR0cmlidXRlcy4gU28sIGFsbG93aW5nIG1vcmUgdGhhbiBvbmUgZW50aXR5IHRvIGFj Y2VwdCB0aGUgZGVsZWdhdGlvbiBhdCBhIGdpdmVuIHRpbWUgKE9SIHJlcXVlc3RpbmcgY29udHJv bCBvZiBhIExTUCB0byBtb3JlIHRoYW4gb25lIFBDRXMpIGlzIG5vdCBnb2luZyB0byB3b3JrLiBE b2VzIGFkZGluZyBhIGV4cGxpY2l0IHJlZmVyZW5jZSB0byB0aGUgZHJhZnQgd2hlcmUgZGVsZWdh dGlvbiBpcyBkZWZpbmVkIHdvcmsgZm9yIHlvdT8NCg0KPT0+DQoNClRoaXMgbWF5IG5vdCBiZSBz byBvYnZpb3VzLCBidXQgd2l0aCBjdXJyZW50IHByb3RvY29sIHNwZWNpZmljYXRpb25zLCB3ZSBt dXN0IHVzZSBQQ0VzIGluIHRoaXMgbWFubmVyLg0KSSBhbSBmaW5lIHdpdGggY3VycmVudCB0ZXh0 IChubyBuZWVkIGZvciBjaGFuZ2UpLg0KDQo8WElBTj46IEkgdGhpbmsgeW91IGNhcHR1cmVkIHRo ZSBpbnRlbnRpb24gd2VsbCBpbiB0aGUgMm5kIGNhc2UgeW91ciBlbGFib3JhdGVkLiBUaGlzIHVz ZSBjYXNlIGFzc3VtZXMgdGhlIHVzZSBvZiBhbiBhY3RpdmUgc3RhdGVmdWwgUENFIHdoaWNoIGNh biB0cmlnZ2VyIHJlLWNvbXB1dGF0aW9uIGJhc2VkIG9uIHRyaWdnZXIgc3VjaCBhcyBidXQgbm90 IGxpbWl0ZWQgZmFpbHVyZXMsIHJhdGhlciB0aGFuIGJhc2VkIG9uIHVuZGV0ZXJtaW5lZCBzZXF1 ZW50aWFsIGNvbXB1dGF0aW9uIHJlcXVlc3RzLiBIb3cgYWJvdXQgZXhwYW5kaW5nIHRoZSBsYXN0 IHNlbnRlbmNlIGFzIHRoZSBmb2xsb3dpbmc/DQoNCk9MRDogDQpBIHN0YXRlZnVsIFBDRSBjYW4g c29sdmUgdGhpcyB0aHJvdWdoIGNvbnRyb2wgb3ZlciBMU1Agb3JkZXJpbmcuDQpORVc6IA0KQW4g YWN0aXZlIHN0YXRlZnVsIFBDRSBjYW4gc29sdmUgdGhpcyB0aHJvdWdoIGNvbnRyb2wgb3ZlciBM U1Agb3JkZXJpbmcuIEJhc2VkIG9uIHRyaWdnZXJzIHN1Y2ggYXMgYSBmYWlsdXJlIG9yIGFuIG9w dGltaXphdGlvbiB0cmlnZ2VyLCB0aGUgUENFIGNhbiBvcmRlciB0aGUgY29tcHV0YXRpb25zIGFu ZCBwYXRoIHNldHVwIGluIGEgZGV0ZXJtaW5pc3RpYyB3YXkuDQoNCj09Pg0KDQpUaGFua3MgZm9y IGNsYXJpZmljYXRpb24uIFByb3Bvc2VkIG5ldyB0ZXh0IGxvb2tzIGdvb2QgdG8gbWUuDQoNClRo YW5rcywNClRvbW9ub3JpIFRha2VkYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogcnRnLWRpciBbbWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFpoYW5neGlhbiAoWGlhbikNClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNiAzOjIw IFBNDQpUbzogVG9tb25vcmkgVGFrZWRho6jO5Mzv1qq15KOpOyAncnRnLWFkc0BpZXRmLm9yZycN CkNjOiAncnRnLWRpckBpZXRmLm9yZyc7IEluYSBNaW5laTsgJ3BjZUBpZXRmLm9yZyc7IERocnV2 IERob2R5OyAnZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcEBpZXRmLm9yZycNClN1Ympl Y3Q6IFJlOiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwt cGNlLWFwcC0wNi50eHQNCg0KSGksIFRvbW9ub3JpIFRha2VkYSwgDQoNCiAgIFRoYW5rIHlvdSB2 ZXJ5IG11Y2ggZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcuIFdpdGggcmVnYXJkIHRvIHRoZSB0d28g bWlub3IgaXNzdWVzIHlvdSByYWlzZWQsIHBsZWFzZSBzZWUgaW5saW5lIG1hcmtlZCB3aXRoIDxY SUFOPjogDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBUb21vbm9yaSBUYWtlZGEgW21h aWx0bzp0b21vbm9yaS50YWtlZGFAbnR0LmNvbV0gDQq3osvNyrG85DogMjAxNsTqOdTCOcjVIDIy OjQ2DQrK1bz+yMs6ICdydGctYWRzQGlldGYub3JnJw0Ks63LzTogJ3J0Zy1kaXJAaWV0Zi5vcmcn OyAnZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcEBpZXRmLm9yZyc7ICdwY2VAaWV0Zi5v cmcnDQrW98ziOiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtYXBw LTA2LnR4dA0KDQpIZWxsbywNCg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcg RGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9y YXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRz IGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5k IHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcg aXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3Vn aCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5n IEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9u ZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZl LCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBk YXRpbmcgdGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNl LWFwcC0wNi50eHQNClJldmlld2VyOiBUb21vbm9yaSBUYWtlZGENClJldmlldyBEYXRlOiBTZXB0 ZW1iZXIgOXRoLCAyMDE2DQpJRVRGIExDIEVuZCBEYXRlOiBOb3Qga25vd24NCkludGVuZGVkIFN0 YXR1czogSW5mb3JtYXRpb25hbA0KDQpTdW1tYXJ5OiANCg0KSSBoYXZlIHNvbWUgbWlub3IgY29u Y2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVk IGJlZm9yZSBwdWJsaWNhdGlvbi4gDQoNCkNvbW1lbnRzOiANCg0KVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYXBwbGljYWJpbGl0eSBvZiBhIHN0YXRlZnVsIFBDRSwgYXMgd2VsbCBhcyBnZW5lcmFs IGNvbnNpZGVyYXRpb25zIGZvciBkZXBsb3ltZW50LiBUaGUgZG9jdW1lbnQgaXMgd2VsbCBvcmdh bml6ZWQgYW5kIGVhc3kgdG8gcmVhZC4gSG93ZXZlciwgdGhlcmUgYXJlIHNvbWUgbWlub3IgcG9p bnRzIHdoaWNoIEkgdGhpbmsgc2hvdWxkIGJlIGNsYXJpZmllZCBmb3IgY29tcGxldGVuZXNzIGFu ZCBlYXNpbmVzcyB0byByZWFkeS4NCg0KTWFqb3IgSXNzdWVzOiANCg0KTm9uZQ0KDQpNaW5vciBJ c3N1ZXM6IA0KDQoxKSBJbiBwYWdlIDUsIHNlY3Rpb24gNC4xLCBtdWx0aS1QQ0UgZGVwbG95bWVu dHMgYXJlIGRlc2NyaWJlZC4gSXQgc2F5cywgIlJlZ2FyZGxlc3Mgb2YgdGhlIHJlYXNvbiBmb3Ig bXVsdGlwbGUgUENFcywgYW4gTFNQIGlzIG9ubHkgZGVsZWdhdGVkIHRvIG9uZSBvZiB0aGUgUENF cyBhdCBhbnkgZ2l2ZW4gcG9pbnQgaW4gdGltZS4iIElzIHRoaXMgZGVzY3JpYmVkL2RlZmluZWQg aW4gc29tZSBvdGhlciBkb2N1bWVudCwgb3IgaW4gdGhpcyBkb2N1bWVudD8gSW4gdGhlIGZpcnN0 IGNhc2UsIHBsZWFzZSBpbmRpY2F0ZSBhIHJlZmVyZW5jZS4gSW4gdGhlIGxhdHRlciBjYXNlLCBJ IHdvdWxkIGxpa2UgdG8gc2VlIG1vcmUgY2xhcmlmaWNhdGlvbiBhbmQgcmVhc29uaW5nLg0KIDxY SUFOPjogV2UgYWN0dWFsbHkgdGFrZSB0aGlzIGFzIGEgY29tbW9ubHkgYWdyZWVkIGFzc3VtcHRp b24gYW5kIGl0IGlzIGFsc28gc3RhdGVkIGluIDwgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS0xNj4uIEFzIHNwZWNpZmllZCBpbiB0aGF0IGRy YWZ0IFNlY3Rpb24gMiwgZGVsZWdhdGlvbiBtZWFucyB0aGF0IHdob2V2ZXIgYWNjZXB0cyB0aGlz IGRlbGVnYXRpb24gd2lsbCBiZSBhYmxlIHRvIGNoYW5nZSBpdHMgYXR0cmlidXRlcy4gU28sIGFs bG93aW5nIG1vcmUgdGhhbiBvbmUgZW50aXR5IHRvIGFjY2VwdCB0aGUgZGVsZWdhdGlvbiBhdCBh IGdpdmVuIHRpbWUgKE9SIHJlcXVlc3RpbmcgY29udHJvbCBvZiBhIExTUCB0byBtb3JlIHRoYW4g b25lIFBDRXMpIGlzIG5vdCBnb2luZyB0byB3b3JrLiBEb2VzIGFkZGluZyBhIGV4cGxpY2l0IHJl ZmVyZW5jZSB0byB0aGUgZHJhZnQgd2hlcmUgZGVsZWdhdGlvbiBpcyBkZWZpbmVkIHdvcmsgZm9y IHlvdT8NCg0KMikgSW4gcGFnZSAxMiwgc2VjdGlvbiA1LjEuNCwgcHJlZGljdGFiaWxpdHkgaXMg ZGVzY3JpYmVkIGFzIGFuIGFwcGxpY2F0aW9uLiBJdCBzYXlzICJBIHN0YXRlZnVsIFBDRSBjYW4g c29sdmUgdGhpcyB0aHJvdWdoIGNvbnRyb2wgb3ZlciBMU1Agb3JkZXJpbmcuIiwgYnV0IEkgYW0g bm90IHN1cmUgaG93IHN0YXRlZnVsIFBDRSBzb2x2ZXMgdGhpcyBzY2VuYXJpby4gSXMgaXQgcG9z c2libGUgZXZlbiBpZiBjb21wdXRhdGlvbiByZXF1ZXN0cyBjb21lIGluIGEgdGltZSBzZXJpZXM/ IE9yIGlzIGl0IGFzc3VtZWQgdGhhdCBhIHN0YXRlZnVsIFBDRSBpcyB1c2VkIGluIHN1Y2ggYSB3 YXkgdGhhdCBjb21wdXRhdGlvbiByZXF1ZXN0cyBkbyBub3QgY29tZSBpbiBhIHRpbWUgc2VyaWVz PyAoRm9yIGV4YW1wbGUsIGluIGEgZmFpbHVyZSBzY2VuYXJpbywgTFNQIHJlLWNvbXB1dGF0aW9u IGlzIG5vdCB0cmlnZ2VyZWQgYnkgUENDIHJlcXVlc3RpbmcgcGF0aCBjb21wdXRhdGlvbiwgYnV0 IGJ5IGxpbmsgZmFpbHVyZT8pDQoNCjxYSUFOPjogSSB0aGluayB5b3UgY2FwdHVyZWQgdGhlIGlu dGVudGlvbiB3ZWxsIGluIHRoZSAybmQgY2FzZSB5b3VyIGVsYWJvcmF0ZWQuIFRoaXMgdXNlIGNh c2UgYXNzdW1lcyB0aGUgdXNlIG9mIGFuIGFjdGl2ZSBzdGF0ZWZ1bCBQQ0Ugd2hpY2ggY2FuIHRy aWdnZXIgcmUtY29tcHV0YXRpb24gYmFzZWQgb24gdHJpZ2dlciBzdWNoIGFzIGJ1dCBub3QgbGlt aXRlZCBmYWlsdXJlcywgcmF0aGVyIHRoYW4gYmFzZWQgb24gdW5kZXRlcm1pbmVkIHNlcXVlbnRp YWwgY29tcHV0YXRpb24gcmVxdWVzdHMuIEhvdyBhYm91dCBleHBhbmRpbmcgdGhlIGxhc3Qgc2Vu dGVuY2UgYXMgdGhlIGZvbGxvd2luZz8NCg0KT0xEOiANCkEgc3RhdGVmdWwgUENFIGNhbiBzb2x2 ZSB0aGlzIHRocm91Z2ggY29udHJvbCBvdmVyIExTUCBvcmRlcmluZy4NCk5FVzogDQpBbiBhY3Rp dmUgc3RhdGVmdWwgUENFIGNhbiBzb2x2ZSB0aGlzIHRocm91Z2ggY29udHJvbCBvdmVyIExTUCBv cmRlcmluZy4gQmFzZWQgb24gdHJpZ2dlcnMgc3VjaCBhcyBhIGZhaWx1cmUgb3IgYW4gb3B0aW1p emF0aW9uIHRyaWdnZXIsIHRoZSBQQ0UgY2FuIG9yZGVyIHRoZSBjb21wdXRhdGlvbnMgYW5kIHBh dGggc2V0dXAgaW4gYSBkZXRlcm1pbmlzdGljIHdheS4gDQoNClJlZ2FyZHMsDQpYaWFuIChvbiBi ZWhhbGYgb2YgYWxsIGF1dGhvcnMvY29udHJpYnV0b3JzKQ0KDQpOaXRzOg0KDQpOb25lDQoNClRo YW5rcywNClRvbW9ub3JpIFRha2VkYQ0K From nobody Tue Sep 13 07:01:08 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D54D12B67A; Tue, 13 Sep 2016 07:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 aq81eRLZDI42; Tue, 13 Sep 2016 07:01:01 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 9ECC312B45A; Tue, 13 Sep 2016 06:33:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.155; From: "Susan Hares" To: "'Emmanuel Baccelli'" , References: In-Reply-To: Date: Tue, 13 Sep 2016 09:32:28 -0400 Message-ID: <032601d20dc3$460fcc70$d22f6550$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFuExKNWFc/IgzwGEPV/lOHpsckdqE/VKhQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-idr-bgp-gr-notification.all@ietf.org, idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-gr-notification-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 14:01:06 -0000 Emmanuel:=20 Thank you for your review. The authors will create a revision based on = your comments.=20 Sue Hares (IDR WG Co-chair)=20 -----Original Message----- From: emmanuel.baccelli@gmail.com [mailto:emmanuel.baccelli@gmail.com] = On Behalf Of Emmanuel Baccelli Sent: Monday, September 12, 2016 8:05 AM To: Cc: rtg-dir@ietf.org; draft-ietf-idr-bgp-gr-notification.all@ietf.org; = idr@ietf.org Subject: RtgDir review: draft-ietf-idr-bgp-gr-notification-07 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-idr-bgp-gr-notification-07 Reviewer: Emmanuel Baccelli Review Date: Sept. 12th 2016 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that = should be considered prior to publication. Comments: This document is clearly written and easy to understand. I am not a BGP specialist, and in particular I was not familiar with the = details of BGP Graceful restart before I have reviewed, so I had to go = back and read RFC4724. It may mean that my review is not sufficiently in-depth, or that the = nits I point out and my editorial suggestions may be too pedantic. Major Issues: No major issues found. Minor Issues: No minor issues found. Nits: Nits and minor suggestions below can be considered, aiming to improve = readability. Working group indication: - indicate IDR working group at the top of the document (for now it = says "Network working group") Abstract: - for clarity, append at the end of last sentence "and for force a full = reset"? Section 2 - in restart flags, for completeness, recall that R flag is specified = in RFC4724 and what it indicates. - recall that reserved/unspecified fields must be zeroed (and ignored)? - spell out acronyms AFI and SAFI (in terminology section, as coming = from RFC4724?) before first use in the document - in Address family flags: remove "deprecated" specification text Section 4: - "When a BGP speaker resets its session due to a HOLDTIME expiry, it = should generate..." =3D> s/should/SHOULD Section 4.1: - the last paragraph of section 4.2 of RFC4724 states that support for = the stale route retain timer is a MAY. It seems appropriate to specify upfront that this timer is now a MUST? - "This supersedes the "consecutive restarts" requirement of [RFC4724] = S. 4.2." =3D> for convenience indicate which paragraph (3rd paragraph) of = RFC4724 S=3D From nobody Tue Sep 13 09:24:25 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7170012B4EE; Tue, 13 Sep 2016 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ARXB-SbubhNq; Tue, 13 Sep 2016 09:24:22 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2A03812B4D8; Tue, 13 Sep 2016 09:11:08 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8DG502x017840; Tue, 13 Sep 2016 12:11:04 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 25ekw5rebv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Sep 2016 12:11:03 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8DGB2AM014143; Tue, 13 Sep 2016 12:11:02 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8DGAoef013809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Sep 2016 12:10:56 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 13 Sep 2016 16:10:32 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.162]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0301.000; Tue, 13 Sep 2016 12:10:32 -0400 From: "BRUNGARD, DEBORAH A" To: Tomonori Takeda , "'Zhangxian (Xian)'" , "'rtg-ads@ietf.org'" Thread-Topic: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt Thread-Index: AdIKqDg5BThlaDp0Suq7kh+dmeZr1AC2oRmAAAuUukAACgd3QA== Date: Tue, 13 Sep 2016 16:10:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.247.40] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609130235 Archived-At: Cc: "'rtg-dir@ietf.org'" , Ina Minei , Dhruv Dhody , "'draft-ietf-pce-stateful-pce-app@ietf.org'" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 16:24:24 -0000 VGhhbmtzIFRvbW9ub3JpIGZvciB5b3VyICBjYXJlZnVsIHJldmlldyENCkRlYm9yYWgNCg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbW9ub3JpIFRha2VkYSBbbWFp bHRvOnRvbW9ub3JpLnRha2VkYUBudHQuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIg MTMsIDIwMTYgNzozMCBBTQ0KPiBUbzogJ1poYW5neGlhbiAoWGlhbiknIDx6aGFuZy54aWFuQGh1 YXdlaS5jb20+OyAncnRnLWFkc0BpZXRmLm9yZycgPHJ0Zy0NCj4gYWRzQGlldGYub3JnPg0KPiBD YzogJ3J0Zy1kaXJAaWV0Zi5vcmcnIDxydGctZGlyQGlldGYub3JnPjsgSW5hIE1pbmVpIDxpbmFt aW5laUBnb29nbGUuY29tPjsNCj4gJ3BjZUBpZXRmLm9yZycgPHBjZUBpZXRmLm9yZz47IERocnV2 IERob2R5IDxkaHJ1di5kaG9keUBodWF3ZWkuY29tPjsNCj4gJ2RyYWZ0LWlldGYtcGNlLXN0YXRl ZnVsLXBjZS1hcHBAaWV0Zi5vcmcnIDxkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtDQo+IGFw cEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcGNl LXN0YXRlZnVsLXBjZS1hcHAtMDYudHh0DQo+IA0KPiBIaSBYaWFuDQo+IA0KPiBUaGFua3MuDQo+ IA0KPiA8WElBTj46IFdlIGFjdHVhbGx5IHRha2UgdGhpcyBhcyBhIGNvbW1vbmx5IGFncmVlZCBh c3N1bXB0aW9uIGFuZCBpdCBpcyBhbHNvDQo+IHN0YXRlZCBpbiA8IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtMTY+LiBBcw0KPiBzcGVjaWZp ZWQgaW4gdGhhdCBkcmFmdCBTZWN0aW9uIDIsIGRlbGVnYXRpb24gbWVhbnMgdGhhdCB3aG9ldmVy IGFjY2VwdHMgdGhpcw0KPiBkZWxlZ2F0aW9uIHdpbGwgYmUgYWJsZSB0byBjaGFuZ2UgaXRzIGF0 dHJpYnV0ZXMuIFNvLCBhbGxvd2luZyBtb3JlIHRoYW4gb25lDQo+IGVudGl0eSB0byBhY2NlcHQg dGhlIGRlbGVnYXRpb24gYXQgYSBnaXZlbiB0aW1lIChPUiByZXF1ZXN0aW5nIGNvbnRyb2wgb2Yg YSBMU1ANCj4gdG8gbW9yZSB0aGFuIG9uZSBQQ0VzKSBpcyBub3QgZ29pbmcgdG8gd29yay4gRG9l cyBhZGRpbmcgYSBleHBsaWNpdCByZWZlcmVuY2UNCj4gdG8gdGhlIGRyYWZ0IHdoZXJlIGRlbGVn YXRpb24gaXMgZGVmaW5lZCB3b3JrIGZvciB5b3U/DQo+IA0KPiA9PT4NCj4gDQo+IFRoaXMgbWF5 IG5vdCBiZSBzbyBvYnZpb3VzLCBidXQgd2l0aCBjdXJyZW50IHByb3RvY29sIHNwZWNpZmljYXRp b25zLCB3ZSBtdXN0DQo+IHVzZSBQQ0VzIGluIHRoaXMgbWFubmVyLg0KPiBJIGFtIGZpbmUgd2l0 aCBjdXJyZW50IHRleHQgKG5vIG5lZWQgZm9yIGNoYW5nZSkuDQo+IA0KPiA8WElBTj46IEkgdGhp bmsgeW91IGNhcHR1cmVkIHRoZSBpbnRlbnRpb24gd2VsbCBpbiB0aGUgMm5kIGNhc2UgeW91cg0K PiBlbGFib3JhdGVkLiBUaGlzIHVzZSBjYXNlIGFzc3VtZXMgdGhlIHVzZSBvZiBhbiBhY3RpdmUg c3RhdGVmdWwgUENFIHdoaWNoIGNhbg0KPiB0cmlnZ2VyIHJlLWNvbXB1dGF0aW9uIGJhc2VkIG9u IHRyaWdnZXIgc3VjaCBhcyBidXQgbm90IGxpbWl0ZWQgZmFpbHVyZXMsDQo+IHJhdGhlciB0aGFu IGJhc2VkIG9uIHVuZGV0ZXJtaW5lZCBzZXF1ZW50aWFsIGNvbXB1dGF0aW9uIHJlcXVlc3RzLiBI b3cNCj4gYWJvdXQgZXhwYW5kaW5nIHRoZSBsYXN0IHNlbnRlbmNlIGFzIHRoZSBmb2xsb3dpbmc/ DQo+IA0KPiBPTEQ6DQo+IEEgc3RhdGVmdWwgUENFIGNhbiBzb2x2ZSB0aGlzIHRocm91Z2ggY29u dHJvbCBvdmVyIExTUCBvcmRlcmluZy4NCj4gTkVXOg0KPiBBbiBhY3RpdmUgc3RhdGVmdWwgUENF IGNhbiBzb2x2ZSB0aGlzIHRocm91Z2ggY29udHJvbCBvdmVyIExTUCBvcmRlcmluZy4gQmFzZWQN Cj4gb24gdHJpZ2dlcnMgc3VjaCBhcyBhIGZhaWx1cmUgb3IgYW4gb3B0aW1pemF0aW9uIHRyaWdn ZXIsIHRoZSBQQ0UgY2FuIG9yZGVyIHRoZQ0KPiBjb21wdXRhdGlvbnMgYW5kIHBhdGggc2V0dXAg aW4gYSBkZXRlcm1pbmlzdGljIHdheS4NCj4gDQo+ID09Pg0KPiANCj4gVGhhbmtzIGZvciBjbGFy aWZpY2F0aW9uLiBQcm9wb3NlZCBuZXcgdGV4dCBsb29rcyBnb29kIHRvIG1lLg0KPiANCj4gVGhh bmtzLA0KPiBUb21vbm9yaSBUYWtlZGENCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IHJ0Zy1kaXIgW21haWx0bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBaaGFuZ3hpYW4gKFhpYW4pDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywg MjAxNiAzOjIwIFBNDQo+IFRvOiBUb21vbm9yaSBUYWtlZGGjqM7kzO/WqrXko6k7ICdydGctYWRz QGlldGYub3JnJw0KPiBDYzogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyBJbmEgTWluZWk7ICdwY2VAaWV0 Zi5vcmcnOyBEaHJ1diBEaG9keTsgJ2RyYWZ0LWlldGYtcGNlLQ0KPiBzdGF0ZWZ1bC1wY2UtYXBw QGlldGYub3JnJw0KPiBTdWJqZWN0OiBSZTogW1JURy1ESVJdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0 LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1hcHAtMDYudHh0DQo+IA0KPiBIaSwgVG9tb25vcmkgVGFr ZWRhLA0KPiANCj4gICAgVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIHJldmll dy4gV2l0aCByZWdhcmQgdG8gdGhlIHR3byBtaW5vcg0KPiBpc3N1ZXMgeW91IHJhaXNlZCwgcGxl YXNlIHNlZSBpbmxpbmUgbWFya2VkIHdpdGggPFhJQU4+Og0KPiANCj4gLS0tLS3Tyrz+1K28/i0t LS0tDQo+ILeivP7IyzogVG9tb25vcmkgVGFrZWRhIFttYWlsdG86dG9tb25vcmkudGFrZWRhQG50 dC5jb21dDQo+ILeiy83KsbzkOiAyMDE2xOo51MI5yNUgMjI6NDYNCj4gytW8/sjLOiAncnRnLWFk c0BpZXRmLm9yZycNCj4gs63LzTogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1wY2Ut c3RhdGVmdWwtcGNlLWFwcEBpZXRmLm9yZyc7DQo+ICdwY2VAaWV0Zi5vcmcnDQo+INb3zOI6IFJ0 Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS1hcHAtMDYudHh0DQo+IA0K PiBIZWxsbywNCj4gDQo+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVj dG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUNCj4gUm91dGluZyBEaXJlY3RvcmF0 ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBh cw0KPiB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFu ZCBzb21ldGltZXMgb24gc3BlY2lhbA0KPiByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2 aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZw0KPiBBRHMuIEZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2Vl DQo+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIN Cj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIFJvdXRpbmcgQURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBj b25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdA0KPiBDYWxsIGNvbW1l bnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gg ZGlzY3Vzc2lvbg0KPiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVudDog ZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcC0wNi50eHQNCj4gUmV2aWV3ZXI6IFRvbW9u b3JpIFRha2VkYQ0KPiBSZXZpZXcgRGF0ZTogU2VwdGVtYmVyIDl0aCwgMjAxNg0KPiBJRVRGIExD IEVuZCBEYXRlOiBOb3Qga25vd24NCj4gSW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFsDQo+ IA0KPiBTdW1tYXJ5Og0KPiANCj4gSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhp cyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlDQo+IHJlc29sdmVkIGJlZm9yZSBwdWJs aWNhdGlvbi4NCj4gDQo+IENvbW1lbnRzOg0KPiANCj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg YXBwbGljYWJpbGl0eSBvZiBhIHN0YXRlZnVsIFBDRSwgYXMgd2VsbCBhcyBnZW5lcmFsDQo+IGNv bnNpZGVyYXRpb25zIGZvciBkZXBsb3ltZW50LiBUaGUgZG9jdW1lbnQgaXMgd2VsbCBvcmdhbml6 ZWQgYW5kIGVhc3kgdG8NCj4gcmVhZC4gSG93ZXZlciwgdGhlcmUgYXJlIHNvbWUgbWlub3IgcG9p bnRzIHdoaWNoIEkgdGhpbmsgc2hvdWxkIGJlIGNsYXJpZmllZA0KPiBmb3IgY29tcGxldGVuZXNz IGFuZCBlYXNpbmVzcyB0byByZWFkeS4NCj4gDQo+IE1ham9yIElzc3VlczoNCj4gDQo+IE5vbmUN Cj4gDQo+IE1pbm9yIElzc3VlczoNCj4gDQo+IDEpIEluIHBhZ2UgNSwgc2VjdGlvbiA0LjEsIG11 bHRpLVBDRSBkZXBsb3ltZW50cyBhcmUgZGVzY3JpYmVkLiBJdCBzYXlzLA0KPiAiUmVnYXJkbGVz cyBvZiB0aGUgcmVhc29uIGZvciBtdWx0aXBsZSBQQ0VzLCBhbiBMU1AgaXMgb25seSBkZWxlZ2F0 ZWQgdG8gb25lIG9mDQo+IHRoZSBQQ0VzIGF0IGFueSBnaXZlbiBwb2ludCBpbiB0aW1lLiIgSXMg dGhpcyBkZXNjcmliZWQvZGVmaW5lZCBpbiBzb21lIG90aGVyDQo+IGRvY3VtZW50LCBvciBpbiB0 aGlzIGRvY3VtZW50PyBJbiB0aGUgZmlyc3QgY2FzZSwgcGxlYXNlIGluZGljYXRlIGEgcmVmZXJl bmNlLg0KPiBJbiB0aGUgbGF0dGVyIGNhc2UsIEkgd291bGQgbGlrZSB0byBzZWUgbW9yZSBjbGFy aWZpY2F0aW9uIGFuZCByZWFzb25pbmcuDQo+ICA8WElBTj46IFdlIGFjdHVhbGx5IHRha2UgdGhp cyBhcyBhIGNvbW1vbmx5IGFncmVlZCBhc3N1bXB0aW9uIGFuZCBpdCBpcyBhbHNvDQo+IHN0YXRl ZCBpbiA8IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1 bC1wY2UtMTY+LiBBcw0KPiBzcGVjaWZpZWQgaW4gdGhhdCBkcmFmdCBTZWN0aW9uIDIsIGRlbGVn YXRpb24gbWVhbnMgdGhhdCB3aG9ldmVyIGFjY2VwdHMgdGhpcw0KPiBkZWxlZ2F0aW9uIHdpbGwg YmUgYWJsZSB0byBjaGFuZ2UgaXRzIGF0dHJpYnV0ZXMuIFNvLCBhbGxvd2luZyBtb3JlIHRoYW4g b25lDQo+IGVudGl0eSB0byBhY2NlcHQgdGhlIGRlbGVnYXRpb24gYXQgYSBnaXZlbiB0aW1lIChP UiByZXF1ZXN0aW5nIGNvbnRyb2wgb2YgYSBMU1ANCj4gdG8gbW9yZSB0aGFuIG9uZSBQQ0VzKSBp cyBub3QgZ29pbmcgdG8gd29yay4gRG9lcyBhZGRpbmcgYSBleHBsaWNpdCByZWZlcmVuY2UNCj4g dG8gdGhlIGRyYWZ0IHdoZXJlIGRlbGVnYXRpb24gaXMgZGVmaW5lZCB3b3JrIGZvciB5b3U/DQo+ IA0KPiAyKSBJbiBwYWdlIDEyLCBzZWN0aW9uIDUuMS40LCBwcmVkaWN0YWJpbGl0eSBpcyBkZXNj cmliZWQgYXMgYW4gYXBwbGljYXRpb24uIEl0DQo+IHNheXMgIkEgc3RhdGVmdWwgUENFIGNhbiBz b2x2ZSB0aGlzIHRocm91Z2ggY29udHJvbCBvdmVyIExTUCBvcmRlcmluZy4iLCBidXQgSQ0KPiBh bSBub3Qgc3VyZSBob3cgc3RhdGVmdWwgUENFIHNvbHZlcyB0aGlzIHNjZW5hcmlvLiBJcyBpdCBw b3NzaWJsZSBldmVuIGlmDQo+IGNvbXB1dGF0aW9uIHJlcXVlc3RzIGNvbWUgaW4gYSB0aW1lIHNl cmllcz8gT3IgaXMgaXQgYXNzdW1lZCB0aGF0IGEgc3RhdGVmdWwNCj4gUENFIGlzIHVzZWQgaW4g c3VjaCBhIHdheSB0aGF0IGNvbXB1dGF0aW9uIHJlcXVlc3RzIGRvIG5vdCBjb21lIGluIGEgdGlt ZQ0KPiBzZXJpZXM/IChGb3IgZXhhbXBsZSwgaW4gYSBmYWlsdXJlIHNjZW5hcmlvLCBMU1AgcmUt Y29tcHV0YXRpb24gaXMgbm90IHRyaWdnZXJlZA0KPiBieSBQQ0MgcmVxdWVzdGluZyBwYXRoIGNv bXB1dGF0aW9uLCBidXQgYnkgbGluayBmYWlsdXJlPykNCj4gDQo+IDxYSUFOPjogSSB0aGluayB5 b3UgY2FwdHVyZWQgdGhlIGludGVudGlvbiB3ZWxsIGluIHRoZSAybmQgY2FzZSB5b3VyDQo+IGVs YWJvcmF0ZWQuIFRoaXMgdXNlIGNhc2UgYXNzdW1lcyB0aGUgdXNlIG9mIGFuIGFjdGl2ZSBzdGF0 ZWZ1bCBQQ0Ugd2hpY2ggY2FuDQo+IHRyaWdnZXIgcmUtY29tcHV0YXRpb24gYmFzZWQgb24gdHJp Z2dlciBzdWNoIGFzIGJ1dCBub3QgbGltaXRlZCBmYWlsdXJlcywNCj4gcmF0aGVyIHRoYW4gYmFz ZWQgb24gdW5kZXRlcm1pbmVkIHNlcXVlbnRpYWwgY29tcHV0YXRpb24gcmVxdWVzdHMuIEhvdw0K PiBhYm91dCBleHBhbmRpbmcgdGhlIGxhc3Qgc2VudGVuY2UgYXMgdGhlIGZvbGxvd2luZz8NCj4g DQo+IE9MRDoNCj4gQSBzdGF0ZWZ1bCBQQ0UgY2FuIHNvbHZlIHRoaXMgdGhyb3VnaCBjb250cm9s IG92ZXIgTFNQIG9yZGVyaW5nLg0KPiBORVc6DQo+IEFuIGFjdGl2ZSBzdGF0ZWZ1bCBQQ0UgY2Fu IHNvbHZlIHRoaXMgdGhyb3VnaCBjb250cm9sIG92ZXIgTFNQIG9yZGVyaW5nLiBCYXNlZA0KPiBv biB0cmlnZ2VycyBzdWNoIGFzIGEgZmFpbHVyZSBvciBhbiBvcHRpbWl6YXRpb24gdHJpZ2dlciwg dGhlIFBDRSBjYW4gb3JkZXIgdGhlDQo+IGNvbXB1dGF0aW9ucyBhbmQgcGF0aCBzZXR1cCBpbiBh IGRldGVybWluaXN0aWMgd2F5Lg0KPiANCj4gUmVnYXJkcywNCj4gWGlhbiAob24gYmVoYWxmIG9m IGFsbCBhdXRob3JzL2NvbnRyaWJ1dG9ycykNCj4gDQo+IE5pdHM6DQo+IA0KPiBOb25lDQo+IA0K PiBUaGFua3MsDQo+IFRvbW9ub3JpIFRha2VkYQ0K From nobody Tue Sep 13 11:43:42 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B543F12B4D8; Tue, 13 Sep 2016 11:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvF3SU1xSR0A; Tue, 13 Sep 2016 11:43:34 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0125.outbound.protection.outlook.com [104.47.38.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26ECB12B029; Tue, 13 Sep 2016 11:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RXes7pkiv8dwjdGa3VoBbbUEop101ojA0HkX5JRSbIY=; b=hEnhpTgJ4buUQCU3PoR9+7IOOn34/CVbeqiSBfy4VjUi79RybgF//JOJ/sa3bp7e7+bOUFyoYyBdl3YrSKNka81M8YP/+fY0MVeSOdbPPrhFZBpI0Cqu+PdCySSJvfdSlCwnsg/p86E1mCGjeJROtLA6J2b2tq8eAaI597Kk/to= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=jgs@juniper.net; Received: from lmacneil-sslvpn-nc.jnpr.net (66.129.241.10) by BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.609.3; Tue, 13 Sep 2016 18:43:30 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "John G. Scudder" In-Reply-To: Date: Tue, 13 Sep 2016 14:43:23 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Emmanuel Baccelli X-Mailer: Apple Mail (2.3124) X-Originating-IP: [66.129.241.10] X-ClientProxiedBy: CY1PR21CA0063.namprd21.prod.outlook.com (10.163.250.159) To BN3PR05MB2500.namprd05.prod.outlook.com (10.167.3.135) X-MS-Office365-Filtering-Correlation-Id: 70c8a1be-ea25-4469-748b-08d3dc05dcdc X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 2:i4Y2zQKyNWDbh7irikDoxeyYXw32MO5DzhkKk6ADOkp6H2W9PvmRES2qXWRxWWFi2dp5aNLlXyOE+tm/req/YW6ywwTn75HtGnqRHksKPDgPLSUZ6h7A67S2G65fhZjFY9wH6QHB422Jd2y0Sjp2ZCvMhfvfGIEeKsiAdyTmOPiSCWjLxb0SKfbasHGDrRoW; 3:hkh68AbeZcmK82U4kLgNwii2qbshNyCPDFQSkE10+bx+D6hnJGUj9AUP0sjZ53SjJ/wFcbzWAAfD4xpsPLDnXEpRWzrJLFANUl6t9226FGGUc1GpdXSE3dYnJkltp+qZ; 25:ekMT95aQ0hET6a995k6mbCRM05CGQwsRXizu6szlI6kbDNjByZ0WF1Kdla+lATxW5dJGCBNScluRPax8Gdge+JssErOLLERnGGbJJ3g6GJEWZCaDAwW6ElxeOEgLALawwNil33sMkq88c7ppdSg4EGlgnwovomZs54YB2yb2L18dsZbstl6h5XP+4lozRVN3MSkl3fe4jJNcdn18MpnZqvTe1SdAS+klh8Be6Brfa6oRdCOvcLA6PJvlryylA2GAbAag+3aGhPyI8Z1C+RSj81wnq2FMyNll9RYgzmw4IWB6LfahY2OSci0w3UfO7hUaODw8wnBxYt76bflRzN3RFXurBH5oU7QMLzfSKoHqjJJ3cr7vFKp5GsdxZ3/UhrclmronnWXCtXVnAtieR+86epIXhbDuJEXTS17pe0/ObCk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 31:4+EO3sDPSVwv/c9A3ebRU0o7I389mTf77yW4/wpgkRTGEZUYcGL/4rDCJoC6cTNRLnPKtADpaIJrBphNnxwzM1pni6CY+CAIEhux2ESejOCIcVbfOLMa13bPvEoEZV6LxjoO5edASuZ4rOmJnacDCqB0SVb+WTlvieBFG76gR7KLUTSwWhK/z0R9w6kTnRwS3MsziXBEDiT+NOhynZKNfIunx61wVNhu2cW9pEkNfX0=; 20:CNPdQ47IXsrSSb8fQbAFP+N5uFX4qVyg9KLCKuU/kk6yKzkKNeyQv7S+5vvrcoAhZdeoUUIkuEG40mFGRhmQJJnrZnXz90zRgB1nCW8Io3TU6XcK3cnoFy3ciqc3Z1oWP0ZJSryZK7uF6RYgZtrFF8AVvyXkXZZRBaervgiX5cxA6MqnorjD4SpMtPgzlgD1+ioh9cSQCRwO1nN30c0V4qG2ZhP1q6TXDE/l6GzjXqfH9PV4BSJs9F2ekx1Nrum3oE9STbujSA3gX1YDGOsJKhGqifKjSQG6afsYRXmbXjUMs9n4+/Pj++lijaXb2oQ3zB21TRUK2rscOl2hBjtKmMi6a8Ry881/Hv/uvd0CF8ttnYaYG8DDpyzCcx4OocAWyhgyOTwNsLXMTIMMNAPhTjvQaowYFI3xYaKa0IDQrCdbrXZD9TP9fsPU3hJlBKQeH+tLUWezGFEjnZ9kFPXOgKO9YkMWI/vm10k88B4K4v/RH36RJe7GPG6Z2C1S3+cKGL8Cn6nD1X4xNYagmcI3VZLvBqNvNpkTIf0UIDazuc9njAYTgtNyfVLIgMNyNwQpstJEoB/4MFSFF21GTVqC5tW5lp4AWFs600FH/ZFHPek= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN3PR05MB2500; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2500; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 4:5WLT2FIHpW6GM+pMG7frwzP7oObTyO12IeFB5b1FIyxraKZJA0BhtiwctPAIr9y1Msr+QG9LtHyZSBpx7IkoRJaLQPXBKx3K0rlNfcHfFKuuY9r6zZi2ImpyzBBn/40fCGuoHpRvOgwb0GMqTGYJFjPxwNzpjaRA+uqeoiz6X8teN/J0she7nioTNAZMA1ihKYx9pUfMk9Z7Hn/kMTiD9XDK3+G0gD7UNcdtrBxVr2MlxBDpTUyrHzMqm4gyXbfy/ppCYpX9HtGedRlporjPcxlOoq9fSJPrhSr4A2NYxjuDg6VGZRDIkH0EdY6ec/5sl8EqE7QD4GHfe3MiOEGkJ2uhBRyYWs9CTrLdSOhpoyGPu9EU8Y+CnNRkGCsjfGVaxglZuWHdoWqlKC33ENwjpvR6Z6TjoJ2TxDqRTIZ5Jc8= X-Forefront-PRVS: 0064B3273C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(24454002)(25584004)(377454003)(199003)(51444003)(42186005)(8676002)(50466002)(76176999)(8746002)(81156014)(81166006)(110136003)(1720100001)(66066001)(53416004)(33656002)(5660300001)(105586002)(101416001)(23676002)(2950100001)(83716003)(97736004)(50226002)(50986999)(586003)(86362001)(36756003)(106356001)(19580395003)(305945005)(19580405001)(68736007)(92566002)(6116002)(3846002)(82746002)(230783001)(4326007)(57306001)(47776003)(77096005)(7846002)(7736002)(69596002)(189998001)(2906002)(15650500001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2500; H:lmacneil-sslvpn-nc.jnpr.net; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1TUIyNTAwOzIzOldyN2ZraGRWemtyRjIrYzU1R3JZOE5Xa2pH?= =?utf-8?B?NHg1T25ON21MVGRhK3gyd2kvQ3YwK04rR3dzS1FKcjJNU2RUZkJmTjFqc3dn?= =?utf-8?B?Yk1tbXZqK3NJWTlIYU9Xalk5SS9Ca1hBZDNqZU50TDIrYXo3cTRsUmxXa0kz?= =?utf-8?B?NHIyaFZsWkVxOS9xa3NHMkJMRVZrb3dKSG9HN09KazdRUnpDTkNVWU12OE91?= =?utf-8?B?MGNqa0hBZ3NHcEg0NVhxRFhjV2VVRVgrekpEUTY5a3pHdWRzdXJBTFZjd0Y1?= =?utf-8?B?SExrYjhGUXRmQnpkaGNuckdkQUJHelJYNWpIU3JnN2VkMDFwZFB4TnZib2FB?= =?utf-8?B?MHBDWjQzWDVtdm1OWWJLbStKVTNnc215SWtMU1VQTzhsd25uRzZISmNaNVFW?= =?utf-8?B?d3hOYVVTU0l6Uit4bHhXS0hHN1dVdnBGWDZIeGNTdzRLRXJWM3FxZ3BZUzJx?= =?utf-8?B?cVZlaWQ2dVJyY1JUb09URktob3BxMFgvWnBwSS84eklvWGJ2L0NKbm9kTjdr?= =?utf-8?B?Z05MZTMxTVBWVjVhZC95aE9pdFZCWHJLeXRXWm5MNzZZM1JuVG5TejZzby9r?= =?utf-8?B?bGpNRkJTTXAyNzJUNHZSZjBRZTdmYUpBMmVXVzFzZzl4L0Y4SDZXN0NGMm5r?= =?utf-8?B?aFlFMnFzR2pVQ2xaVFZOUi9rOUtWRW5SOW94dFlMeG5Rc0lrV2VDdmNablFh?= =?utf-8?B?Rm1qRndSNjNzOXF6d0Jkck9wQ3NRSEtiOUVHcnJ2MzR5YUNLS2VCUUllQjMw?= =?utf-8?B?ZDZ2dHNjcERTMEtUUms5d01TcnJoendYSXFXaEZFa3pMcHlEdjQ4MW5lUUJt?= =?utf-8?B?VVdCMFdzV1gxMGMzYkphUlAwMUtBY3FuNU5ROXhUTHhjMTJkWk15dEg3ZUlF?= =?utf-8?B?SVhBVmR1Sjh5OUZpNnNEMWQ2MU9KK3oxK0E1M3lFS2tYRDhwRG1ka3RNdVZD?= =?utf-8?B?QitYSHloc3lXUGtSKzhGVk5BS0N4Tnc2ZWFZa0VDcERBL2Jjd0tXMzBVQTBk?= =?utf-8?B?em50V2ZkekhJakYzZnBLWXJyOVYrVWlwai95SldDRTdEekpkL2huUDkrN0Vm?= =?utf-8?B?YllYVFFvdUJDU3UyQWE3c0RnM2wzWE9Pa2tSTGdGNUl0RnF3WUZxTlowdENz?= =?utf-8?B?RldWcWo3YTdpd2VNVW43V3NRYTByQlhYZ1ZUWHl1U1UzMlUybTJYVG5DNzhH?= =?utf-8?B?NnVZb2lseHV1bFo3TmlXOGFQYnBmRFVQVDh5dzA2SllvSUFacVJiRU1sRFRB?= =?utf-8?B?NjFpUlowek5mRXp4NUFjbytLOUNEOTNvd1VhSzNVSXUzWVQ5aUFZbHdRU2JY?= =?utf-8?B?RHF6Y0kydjJGMThFOC9hZHZMV3hrNmZqNmprdXl0R0swN2ltbjZRbWtKN3ha?= =?utf-8?B?eUFSK3BubWRXUzFTVGhwdGNObEk5UGVBd2U3aUl4VXFoUkZyZ256UkxpZzFm?= =?utf-8?B?a2o0QnNvdUJjeXo5WDk2TUlzZ0gya1ZRTVltYUlDb1VnRXFLVlpmKy9tOXVT?= =?utf-8?B?Q1FCS3ZOSzJKYnJyTmtjSW9MUjh3YUtVYzRrZXl1VjNPVlJ0UEsvdjd0TFJX?= =?utf-8?B?elhIYytHZ09OKzJnaUtVUDRWMXliTkVFMWh5UGp2M1g5TTAyMFduMFhxYVpS?= =?utf-8?B?VXJPK1FaZnBWR2d6L2U5d2FpcE9PeC85TFJqbllub1FLbTkyczdzNW5DYzRM?= =?utf-8?B?czcyVlAreUd5OHNUaGlFWm5sWjNxdjJLN3BGaTZZWGJodlNsaVVQWlhrbkM1?= =?utf-8?Q?+Jv6DGsjyrj8g/feky8Px0RbnQs1dhfCE7t8s=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2500; 6:h9qtUML/AOT1OzqWSj5aTAloARjLjdGNDbSmHXBt5uV9TTzD1q9z8WvPqW18p49ju6cbADTI68QVsp1rHB9IONj+cUilRkGt0gml/Xxi/fhl4PYGejIiWoBxha/LNRlfbznq3IBNEg9/MulgQzexkqPShSPp70hGExBdF6z2UuBDEIJg5mD7iv8aCYj1Jatrgl9Gq7rqzroI07Sa6XKnA04SveKWMsWKZA1YJNmAqY8W3TZDeiU5TLh3BFj6xdPlNsJNDvuoasMjnM8U8NCgVIv6Gxz4stxB3nkbKDWMIwX1hJJ8Fs2L4ND93bn7za37qiggiyLyPg921/eDiAFOgA==; 5:KizFSlWd+vHYtI7lXyhuLWlrbn9lHBY+6CqpNHb5/fVxwLxjDOc8eXDZ1vk458vgx5iuMG4AYMF/T8bT/7yQeeEXsSqMDeCnR6FiSeX4XMExb3JvQunwVez1ygpcggweeZucmUsop0CqeY6v+ahj6g==; 24:lJzp7lxL+aQhsbSad/Swm4B208l+Lq411Rs6oY82cWMHuWHeyHLt3FD10Wrb9aIGYibzrfIbBbHGoLLYVG5aEszvbsCs++LKNSynBxHtXTs=; 7:Z7WM+S4GQ58hAjMDYpl+W2uWM7YRNnV1SBofRWG3TWn6aKT4gAGedG6sPubuYYDrkHKQApidnluYr/MVusNALF1Poiu3H+85V1bD+P5VK/3TnpjGdabu77LOBLjkjsKDmSx5aypTbu773O8mlM3PBAR4hNv4SdvlX8LJkIpitkW6Vu4Az/QQnb3oejc1H8VbaWvD5Bzj845yvisV8fg8bQ+y81Z8mfxFN6GQAcma1O72LWK1u37zG0N4L7DqJU8t SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2016 18:43:30.9569 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2500 Archived-At: Cc: "" , rtg-dir@ietf.org, draft-ietf-idr-bgp-gr-notification.all@ietf.org, idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-gr-notification-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 18:43:37 -0000 Hi Emmanuel, Thanks for your review. My questions and comments are in line below. --John > On Sep 12, 2016, at 8:05 AM, Emmanuel Baccelli = 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-idr-bgp-gr-notification-07 > Reviewer: Emmanuel Baccelli > Review Date: Sept. 12th 2016 > Intended Status: Standards Track >=20 > Summary: >=20 > This document is basically ready for publication, but has nits that = should > be considered prior to publication. >=20 > Comments: >=20 > This document is clearly written and easy to understand. > I am not a BGP specialist, and in particular I was not familiar with = the > details of BGP Graceful restart before I have reviewed, so I had to go = back > and read RFC4724. Thanks for doing that, it is particularly helpful to have that sort of = review. > It may mean that my review is not sufficiently in-depth, or that the = nits I > point out and my editorial suggestions may be too pedantic. >=20 >=20 > Major Issues: > No major issues found. >=20 >=20 > Minor Issues: > No minor issues found. >=20 >=20 > Nits: >=20 > Nits and minor suggestions below can be considered, aiming to improve > readability. >=20 > Working group indication: > - indicate IDR working group at the top of the document (for now it = says > "Network working group") It turns out that all IETF drafts say "network working group" on them, = for obscure historical reasons. > Abstract: > - for clarity, append at the end of last sentence "and for force a = full > reset"? Changed (in the source, not yet published as 08 pending this discussion) = to "This document also defines a new BGP NOTIFICATION Cease Error = subcode whose effect is to request a full session restart instead of a = Graceful Restart. " > Section 2 > - in restart flags, for completeness, recall that R flag is specified = in > RFC4724 and what it indicates. Done. > - recall that reserved/unspecified fields must be zeroed (and = ignored)? While this is a good suggestion as general practice, it seems beyond the = scope of the present draft. If others disagree and think it's OK for the = present draft to introduce clarifications and modifications to RFC 4724 = beyond the definition of Notification support, I'd be happy to draft = some text. But for now, I'd say it's better to hold this for a 4724bis. > - spell out acronyms AFI and SAFI (in terminology section, as coming = from > RFC4724?) before first use in the document Expanded terms in-line. > - in Address family flags: remove "deprecated" specification text To be clear, you are suggesting this text should be removed? "The usage of second most significant bit "N" (which was defined in a previous draft version of this specification) is deprecated. This bit = MUST be advertised as 0 and MUST be ignored upon receipt." I am inclined to keep it since as it says, a previous version of the = draft did spec such a flag and we have past experience indicating that = this can cause problems when early implementations operate with more = recent ones. What's your reason for wanting to remove the text? > Section 4: > - "When a BGP speaker resets its session due to a HOLDTIME expiry, it > should generate..." > =3D> s/should/SHOULD I am not inclined to use of the all-caps RFC 2119 language since this is = not a new requirement imposed by the current specification, it's merely = restating an existing requirement. That is, the word "should" is being = used in its normal English sense. To elaborate, it's my practice = whenever using SHOULD in the RFC 2119 sense, to spend a little effort = considering under what circumstances an implementor might ignore the = "SHOULD" and then discuss those in a "MAY" clause. I think doing that = would be outside the scope of this document. If the word "should" causes = readers pain, I'm happy to revise the sentence in a way that uses a = different word. > Section 4.1: > - the last paragraph of section 4.2 of RFC4724 states that support for = the > stale route retain timer is a MAY. > It seems appropriate to specify upfront that this timer is now a MUST? It wasn't our intention to make the timer mandatory. Is there a reason = you think it has to be? (As a practical matter, as far as I know all = implementations do support the timer, but I think that's beside the = point.) > - "This supersedes the "consecutive restarts" requirement of [RFC4724] = S. > 4.2." > =3D> for convenience indicate which paragraph (3rd paragraph) of = RFC4724 S Done. From nobody Tue Sep 13 17:49:53 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A689012B074; Tue, 13 Sep 2016 17:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 UnUgdak_dhph; Tue, 13 Sep 2016 17:49:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3012712B14C; Tue, 13 Sep 2016 17:49:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRF60659; Wed, 14 Sep 2016 00:49:44 +0000 (GMT) Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 14 Sep 2016 01:49:43 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.52]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Wed, 14 Sep 2016 08:49:33 +0800 From: "Zhangxian (Xian)" To: Tomonori Takeda , "'rtg-ads@ietf.org'" Thread-Topic: RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt Thread-Index: AdIKqDg5BThlaDp0Suq7kh+dmeZr1AC2oRmAAAuUukAAHCZdQA== Date: Wed, 14 Sep 2016 00:49:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.139.68] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57D89EA9.009A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5a3b6ba6ec6a384224e41a5f910136c Archived-At: Cc: "'rtg-dir@ietf.org'" , Ina Minei , "'pce@ietf.org'" , Dhruv Dhody , "'draft-ietf-pce-stateful-pce-app@ietf.org'" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pce-stateful-pce-app-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2016 00:49:51 -0000 SGkgVG9tb25vcmksIA0KDQogICBHcmVhdDsgSSB3aWxsIGluY29ycG9yYXRlIHRoZSBjaGFuZ2Vz IGluIHRoZSBuZXh0IGRyYWZ0IHVwZGF0ZS4gDQoNCkNoZWVycywNClhpYW4NCg0KLS0tLS3Tyrz+ 1K28/i0tLS0tDQq3orz+yMs6IFRvbW9ub3JpIFRha2VkYSBbbWFpbHRvOnRvbW9ub3JpLnRha2Vk YUBudHQuY29tXSANCreiy83KsbzkOiAyMDE2xOo51MIxM8jVIDE5OjMwDQrK1bz+yMs6IFpoYW5n eGlhbiAoWGlhbik7ICdydGctYWRzQGlldGYub3JnJw0Ks63LzTogJ3J0Zy1kaXJAaWV0Zi5vcmcn OyBJbmEgTWluZWk7ICdwY2VAaWV0Zi5vcmcnOyBEaHJ1diBEaG9keTsgJ2RyYWZ0LWlldGYtcGNl LXN0YXRlZnVsLXBjZS1hcHBAaWV0Zi5vcmcnDQrW98ziOiBSRTogUnRnRGlyIHJldmlldzogZHJh ZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcC0wNi50eHQNCg0KSGkgWGlhbg0KDQpUaGFua3Mu DQoNCjxYSUFOPjogV2UgYWN0dWFsbHkgdGFrZSB0aGlzIGFzIGEgY29tbW9ubHkgYWdyZWVkIGFz c3VtcHRpb24gYW5kIGl0IGlzIGFsc28gc3RhdGVkIGluIDwgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcGNlLXN0YXRlZnVsLXBjZS0xNj4uIEFzIHNwZWNpZmllZCBpbiB0 aGF0IGRyYWZ0IFNlY3Rpb24gMiwgZGVsZWdhdGlvbiBtZWFucyB0aGF0IHdob2V2ZXIgYWNjZXB0 cyB0aGlzIGRlbGVnYXRpb24gd2lsbCBiZSBhYmxlIHRvIGNoYW5nZSBpdHMgYXR0cmlidXRlcy4g U28sIGFsbG93aW5nIG1vcmUgdGhhbiBvbmUgZW50aXR5IHRvIGFjY2VwdCB0aGUgZGVsZWdhdGlv biBhdCBhIGdpdmVuIHRpbWUgKE9SIHJlcXVlc3RpbmcgY29udHJvbCBvZiBhIExTUCB0byBtb3Jl IHRoYW4gb25lIFBDRXMpIGlzIG5vdCBnb2luZyB0byB3b3JrLiBEb2VzIGFkZGluZyBhIGV4cGxp Y2l0IHJlZmVyZW5jZSB0byB0aGUgZHJhZnQgd2hlcmUgZGVsZWdhdGlvbiBpcyBkZWZpbmVkIHdv cmsgZm9yIHlvdT8NCg0KPT0+DQoNClRoaXMgbWF5IG5vdCBiZSBzbyBvYnZpb3VzLCBidXQgd2l0 aCBjdXJyZW50IHByb3RvY29sIHNwZWNpZmljYXRpb25zLCB3ZSBtdXN0IHVzZSBQQ0VzIGluIHRo aXMgbWFubmVyLg0KSSBhbSBmaW5lIHdpdGggY3VycmVudCB0ZXh0IChubyBuZWVkIGZvciBjaGFu Z2UpLg0KDQo8WElBTj46IEkgdGhpbmsgeW91IGNhcHR1cmVkIHRoZSBpbnRlbnRpb24gd2VsbCBp biB0aGUgMm5kIGNhc2UgeW91ciBlbGFib3JhdGVkLiBUaGlzIHVzZSBjYXNlIGFzc3VtZXMgdGhl IHVzZSBvZiBhbiBhY3RpdmUgc3RhdGVmdWwgUENFIHdoaWNoIGNhbiB0cmlnZ2VyIHJlLWNvbXB1 dGF0aW9uIGJhc2VkIG9uIHRyaWdnZXIgc3VjaCBhcyBidXQgbm90IGxpbWl0ZWQgZmFpbHVyZXMs IHJhdGhlciB0aGFuIGJhc2VkIG9uIHVuZGV0ZXJtaW5lZCBzZXF1ZW50aWFsIGNvbXB1dGF0aW9u IHJlcXVlc3RzLiBIb3cgYWJvdXQgZXhwYW5kaW5nIHRoZSBsYXN0IHNlbnRlbmNlIGFzIHRoZSBm b2xsb3dpbmc/DQoNCk9MRDogDQpBIHN0YXRlZnVsIFBDRSBjYW4gc29sdmUgdGhpcyB0aHJvdWdo IGNvbnRyb2wgb3ZlciBMU1Agb3JkZXJpbmcuDQpORVc6IA0KQW4gYWN0aXZlIHN0YXRlZnVsIFBD RSBjYW4gc29sdmUgdGhpcyB0aHJvdWdoIGNvbnRyb2wgb3ZlciBMU1Agb3JkZXJpbmcuIEJhc2Vk IG9uIHRyaWdnZXJzIHN1Y2ggYXMgYSBmYWlsdXJlIG9yIGFuIG9wdGltaXphdGlvbiB0cmlnZ2Vy LCB0aGUgUENFIGNhbiBvcmRlciB0aGUgY29tcHV0YXRpb25zIGFuZCBwYXRoIHNldHVwIGluIGEg ZGV0ZXJtaW5pc3RpYyB3YXkuDQoNCj09Pg0KDQpUaGFua3MgZm9yIGNsYXJpZmljYXRpb24uIFBy b3Bvc2VkIG5ldyB0ZXh0IGxvb2tzIGdvb2QgdG8gbWUuDQoNClRoYW5rcywNClRvbW9ub3JpIFRh a2VkYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRnLWRpciBbbWFpbHRv OnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFpoYW5neGlhbiAoWGlhbikN ClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNiAzOjIwIFBNDQpUbzogVG9tb25vcmkg VGFrZWRho6jO5Mzv1qq15KOpOyAncnRnLWFkc0BpZXRmLm9yZycNCkNjOiAncnRnLWRpckBpZXRm Lm9yZyc7IEluYSBNaW5laTsgJ3BjZUBpZXRmLm9yZyc7IERocnV2IERob2R5OyAnZHJhZnQtaWV0 Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcEBpZXRmLm9yZycNClN1YmplY3Q6IFJlOiBbUlRHLURJUl0g UnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcC0wNi50eHQNCg0K SGksIFRvbW9ub3JpIFRha2VkYSwgDQoNCiAgIFRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSBk ZXRhaWxlZCByZXZpZXcuIFdpdGggcmVnYXJkIHRvIHRoZSB0d28gbWlub3IgaXNzdWVzIHlvdSBy YWlzZWQsIHBsZWFzZSBzZWUgaW5saW5lIG1hcmtlZCB3aXRoIDxYSUFOPjogDQoNCi0tLS0t08q8 /tStvP4tLS0tLQ0Kt6K8/sjLOiBUb21vbm9yaSBUYWtlZGEgW21haWx0bzp0b21vbm9yaS50YWtl ZGFAbnR0LmNvbV0gDQq3osvNyrG85DogMjAxNsTqOdTCOcjVIDIyOjQ2DQrK1bz+yMs6ICdydGct YWRzQGlldGYub3JnJw0Ks63LzTogJ3J0Zy1kaXJAaWV0Zi5vcmcnOyAnZHJhZnQtaWV0Zi1wY2Ut c3RhdGVmdWwtcGNlLWFwcEBpZXRmLm9yZyc7ICdwY2VAaWV0Zi5vcmcnDQrW98ziOiBSdGdEaXIg cmV2aWV3OiBkcmFmdC1pZXRmLXBjZS1zdGF0ZWZ1bC1wY2UtYXBwLTA2LnR4dA0KDQpIZWxsbywN Cg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3 ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmll dyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJv dWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVj aWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBh cmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUg aGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJ RVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0K DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1wY2Utc3RhdGVmdWwtcGNlLWFwcC0wNi50eHQNClJldmll d2VyOiBUb21vbm9yaSBUYWtlZGENClJldmlldyBEYXRlOiBTZXB0ZW1iZXIgOXRoLCAyMDE2DQpJ RVRGIExDIEVuZCBEYXRlOiBOb3Qga25vd24NCkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25h bA0KDQpTdW1tYXJ5OiANCg0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBk b2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlv bi4gDQoNCkNvbW1lbnRzOiANCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYXBwbGljYWJpbGl0 eSBvZiBhIHN0YXRlZnVsIFBDRSwgYXMgd2VsbCBhcyBnZW5lcmFsIGNvbnNpZGVyYXRpb25zIGZv ciBkZXBsb3ltZW50LiBUaGUgZG9jdW1lbnQgaXMgd2VsbCBvcmdhbml6ZWQgYW5kIGVhc3kgdG8g cmVhZC4gSG93ZXZlciwgdGhlcmUgYXJlIHNvbWUgbWlub3IgcG9pbnRzIHdoaWNoIEkgdGhpbmsg c2hvdWxkIGJlIGNsYXJpZmllZCBmb3IgY29tcGxldGVuZXNzIGFuZCBlYXNpbmVzcyB0byByZWFk eS4NCg0KTWFqb3IgSXNzdWVzOiANCg0KTm9uZQ0KDQpNaW5vciBJc3N1ZXM6IA0KDQoxKSBJbiBw YWdlIDUsIHNlY3Rpb24gNC4xLCBtdWx0aS1QQ0UgZGVwbG95bWVudHMgYXJlIGRlc2NyaWJlZC4g SXQgc2F5cywgIlJlZ2FyZGxlc3Mgb2YgdGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgUENFcywgYW4g TFNQIGlzIG9ubHkgZGVsZWdhdGVkIHRvIG9uZSBvZiB0aGUgUENFcyBhdCBhbnkgZ2l2ZW4gcG9p bnQgaW4gdGltZS4iIElzIHRoaXMgZGVzY3JpYmVkL2RlZmluZWQgaW4gc29tZSBvdGhlciBkb2N1 bWVudCwgb3IgaW4gdGhpcyBkb2N1bWVudD8gSW4gdGhlIGZpcnN0IGNhc2UsIHBsZWFzZSBpbmRp Y2F0ZSBhIHJlZmVyZW5jZS4gSW4gdGhlIGxhdHRlciBjYXNlLCBJIHdvdWxkIGxpa2UgdG8gc2Vl IG1vcmUgY2xhcmlmaWNhdGlvbiBhbmQgcmVhc29uaW5nLg0KIDxYSUFOPjogV2UgYWN0dWFsbHkg dGFrZSB0aGlzIGFzIGEgY29tbW9ubHkgYWdyZWVkIGFzc3VtcHRpb24gYW5kIGl0IGlzIGFsc28g c3RhdGVkIGluIDwgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcGNlLXN0 YXRlZnVsLXBjZS0xNj4uIEFzIHNwZWNpZmllZCBpbiB0aGF0IGRyYWZ0IFNlY3Rpb24gMiwgZGVs ZWdhdGlvbiBtZWFucyB0aGF0IHdob2V2ZXIgYWNjZXB0cyB0aGlzIGRlbGVnYXRpb24gd2lsbCBi ZSBhYmxlIHRvIGNoYW5nZSBpdHMgYXR0cmlidXRlcy4gU28sIGFsbG93aW5nIG1vcmUgdGhhbiBv bmUgZW50aXR5IHRvIGFjY2VwdCB0aGUgZGVsZWdhdGlvbiBhdCBhIGdpdmVuIHRpbWUgKE9SIHJl cXVlc3RpbmcgY29udHJvbCBvZiBhIExTUCB0byBtb3JlIHRoYW4gb25lIFBDRXMpIGlzIG5vdCBn b2luZyB0byB3b3JrLiBEb2VzIGFkZGluZyBhIGV4cGxpY2l0IHJlZmVyZW5jZSB0byB0aGUgZHJh ZnQgd2hlcmUgZGVsZWdhdGlvbiBpcyBkZWZpbmVkIHdvcmsgZm9yIHlvdT8NCg0KMikgSW4gcGFn ZSAxMiwgc2VjdGlvbiA1LjEuNCwgcHJlZGljdGFiaWxpdHkgaXMgZGVzY3JpYmVkIGFzIGFuIGFw cGxpY2F0aW9uLiBJdCBzYXlzICJBIHN0YXRlZnVsIFBDRSBjYW4gc29sdmUgdGhpcyB0aHJvdWdo IGNvbnRyb2wgb3ZlciBMU1Agb3JkZXJpbmcuIiwgYnV0IEkgYW0gbm90IHN1cmUgaG93IHN0YXRl ZnVsIFBDRSBzb2x2ZXMgdGhpcyBzY2VuYXJpby4gSXMgaXQgcG9zc2libGUgZXZlbiBpZiBjb21w dXRhdGlvbiByZXF1ZXN0cyBjb21lIGluIGEgdGltZSBzZXJpZXM/IE9yIGlzIGl0IGFzc3VtZWQg dGhhdCBhIHN0YXRlZnVsIFBDRSBpcyB1c2VkIGluIHN1Y2ggYSB3YXkgdGhhdCBjb21wdXRhdGlv biByZXF1ZXN0cyBkbyBub3QgY29tZSBpbiBhIHRpbWUgc2VyaWVzPyAoRm9yIGV4YW1wbGUsIGlu IGEgZmFpbHVyZSBzY2VuYXJpbywgTFNQIHJlLWNvbXB1dGF0aW9uIGlzIG5vdCB0cmlnZ2VyZWQg YnkgUENDIHJlcXVlc3RpbmcgcGF0aCBjb21wdXRhdGlvbiwgYnV0IGJ5IGxpbmsgZmFpbHVyZT8p DQoNCjxYSUFOPjogSSB0aGluayB5b3UgY2FwdHVyZWQgdGhlIGludGVudGlvbiB3ZWxsIGluIHRo ZSAybmQgY2FzZSB5b3VyIGVsYWJvcmF0ZWQuIFRoaXMgdXNlIGNhc2UgYXNzdW1lcyB0aGUgdXNl IG9mIGFuIGFjdGl2ZSBzdGF0ZWZ1bCBQQ0Ugd2hpY2ggY2FuIHRyaWdnZXIgcmUtY29tcHV0YXRp b24gYmFzZWQgb24gdHJpZ2dlciBzdWNoIGFzIGJ1dCBub3QgbGltaXRlZCBmYWlsdXJlcywgcmF0 aGVyIHRoYW4gYmFzZWQgb24gdW5kZXRlcm1pbmVkIHNlcXVlbnRpYWwgY29tcHV0YXRpb24gcmVx dWVzdHMuIEhvdyBhYm91dCBleHBhbmRpbmcgdGhlIGxhc3Qgc2VudGVuY2UgYXMgdGhlIGZvbGxv d2luZz8NCg0KT0xEOiANCkEgc3RhdGVmdWwgUENFIGNhbiBzb2x2ZSB0aGlzIHRocm91Z2ggY29u dHJvbCBvdmVyIExTUCBvcmRlcmluZy4NCk5FVzogDQpBbiBhY3RpdmUgc3RhdGVmdWwgUENFIGNh biBzb2x2ZSB0aGlzIHRocm91Z2ggY29udHJvbCBvdmVyIExTUCBvcmRlcmluZy4gQmFzZWQgb24g dHJpZ2dlcnMgc3VjaCBhcyBhIGZhaWx1cmUgb3IgYW4gb3B0aW1pemF0aW9uIHRyaWdnZXIsIHRo ZSBQQ0UgY2FuIG9yZGVyIHRoZSBjb21wdXRhdGlvbnMgYW5kIHBhdGggc2V0dXAgaW4gYSBkZXRl cm1pbmlzdGljIHdheS4gDQoNClJlZ2FyZHMsDQpYaWFuIChvbiBiZWhhbGYgb2YgYWxsIGF1dGhv cnMvY29udHJpYnV0b3JzKQ0KDQpOaXRzOg0KDQpOb25lDQoNClRoYW5rcywNClRvbW9ub3JpIFRh a2VkYQ0K From nobody Thu Sep 15 01:44:42 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C436712B494; Thu, 15 Sep 2016 01:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQEWEGxTKp8h; Thu, 15 Sep 2016 01:44:31 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 7B81A12B495; Thu, 15 Sep 2016 01:44:31 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id b81so16173150vkd.0; Thu, 15 Sep 2016 01:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gxAHOf2AuxBneXw1xJERY9ugG558fkG+WyqLSuFqMJA=; b=oaOoSddPzJQ5VyfRylReLFH60ndpOdjaMZRyWR2z8GHL3bPnSHi/Bj7OagJ7T9B7vE G6UQWRBC3kvg+Llo7UaWZrk/5vEs8N+ssZacHZYvpqmtlEbBGlAIcosSoucn1/Yca9EJ NJEHlPk+EOUvgW0nKbuXlRZVu3C1c5+/pmOv7sPuuaez7VWZqVC1yOy35+OgXrOydAQx 840K4vUN7LJ4FcskojLD1PQKV5zwz90+/cHIignEDN/KoSe321he7qZmyrTsHijUMGRH +r7G0/uoLzPC3uuwCFYN5jZdq29SAhc0Acx11lq9L0FHeiro1zDlhsP8Sa7po6gmsDIc Sv2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gxAHOf2AuxBneXw1xJERY9ugG558fkG+WyqLSuFqMJA=; b=UHB1zHu3M3u+j5QPRRGrxI9E3nc7jCP0DzSNuAgkTJDd2U0x0fUl/5coXlLaGxhgzg EfObpJlrGN6H60Wrh1Hqn5NuJ+2b+uNcd+DYX2E0Mde1CLYqb0YBSlG46myH91D+txo1 0pW7XSGXqRMrGasZ+Du3Ky5sm5UWCaPR0k9sDtVTcqH24fOnFltwuu+HH/dgULkmg4u1 xUk4kjiAFBtE1L12P2FJemV0nvJRDsNbZTKJgkKgOw16ZQp0ftaYYWcL6ozA3AOtVieo uxNwoSYKtwb7ufHwkrKOgwqGqotsXKQgdGM90dgo5igBK16rjo8J5qcXDmMpz/3xmR0j nzAQ== X-Gm-Message-State: AE9vXwPB+DnfOg1THDmVvddqr69aFhlrv/2lBBOSenvxm8Lhbfjpb85E0m1bT4xXv4LnvS8ybvUcQ2Q0Tf8XCg== X-Received: by 10.31.3.213 with SMTP id f82mr1721387vki.50.1473929070664; Thu, 15 Sep 2016 01:44:30 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.176.1.113 with HTTP; Thu, 15 Sep 2016 01:44:10 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Thu, 15 Sep 2016 10:44:10 +0200 X-Google-Sender-Auth: 53FFIlqLCTgdI5xDUCdzcI5FZ7U Message-ID: To: "John G. Scudder" Content-Type: multipart/alternative; boundary=001a11426cdeae60f8053c87da93 Archived-At: Cc: "" , rtg-dir@ietf.org, draft-ietf-idr-bgp-gr-notification.all@ietf.org, idr@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-gr-notification-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 08:44:38 -0000 --001a11426cdeae60f8053c87da93 Content-Type: text/plain; charset=UTF-8 Hi John, see comments inline. On Tue, Sep 13, 2016 at 8:43 PM, John G. Scudder wrote: > Hi Emmanuel, > > Thanks for your review. My questions and comments are in line below. > > --John > > > > > Abstract: > > - for clarity, append at the end of last sentence "and for force a full > > reset"? > > Changed (in the source, not yet published as 08 pending this discussion) > to "This document also defines a new BGP NOTIFICATION Cease Error subcode > whose effect is to request a full session restart instead of a Graceful > Restart. " > > Fine with me. > > > - recall that reserved/unspecified fields must be zeroed (and ignored)? > > While this is a good suggestion as general practice, it seems beyond the > scope of the present draft. If others disagree and think it's OK for the > present draft to introduce clarifications and modifications to RFC 4724 > beyond the definition of Notification support, I'd be happy to draft some > text. But for now, I'd say it's better to hold this for a 4724bis. > > OK. This was just a suggestion. However, see next comment below. > > > - in Address family flags: remove "deprecated" specification text > > To be clear, you are suggesting this text should be removed? > > "The usage of second most significant bit "N" (which was defined in a > previous draft version of this specification) is deprecated. This bit MUST > be advertised as 0 and MUST be ignored upon receipt." > > I am inclined to keep it since as it says, a previous version of the draft > did spec such a flag and we have past experience indicating that this can > cause problems when early implementations operate with more recent ones. > What's your reason for wanting to remove the text? > > I see. But on the other hand, in the long term, you are writing an RFC, and in my opinion, it is awkward and confusing to have this kind of text and reference to an early draft version in an RFC. One solution could be to remove the N bit in the figure and recall that as per RFC4724 all reserved bits must be set to zero? The good side is it could fix your problem without referring to "prior versions of the draft". The bad side would be that it is not so great to have exactly the same piece of spec duplicated from RFC4724. I'm not sure there is a perfect solution here. > > Section 4: > > - "When a BGP speaker resets its session due to a HOLDTIME expiry, it > > should generate..." > > => s/should/SHOULD > > I am not inclined to use of the all-caps RFC 2119 language since this is > not a new requirement imposed by the current specification, it's merely > restating an existing requirement. That is, the word "should" is being used > in its normal English sense. To elaborate, it's my practice whenever using > SHOULD in the RFC 2119 sense, to spend a little effort considering under > what circumstances an implementor might ignore the "SHOULD" and then > discuss those in a "MAY" clause. I think doing that would be outside the > scope of this document. If the word "should" causes readers pain, I'm happy > to revise the sentence in a way that uses a different word. > > No strong opinion on that. I let specialists talk it over, if needed. Else, let's do what you propose. > > Section 4.1: > > - the last paragraph of section 4.2 of RFC4724 states that support for > the > > stale route retain timer is a MAY. > > It seems appropriate to specify upfront that this timer is now a MUST? > > It wasn't our intention to make the timer mandatory. Is there a reason you > think it has to be? (As a practical matter, as far as I know all > implementations do support the timer, but I think that's beside the point.) > > When one reads the current spec: on one hand, I understand that you MUST do something when this timer fires, on the other hand, in RFC4724, this timer MAY be used. So one naturally wonders what happens if this timer is not implemented: can it cause problems? I was thus suggesting that making this timer mandatory would be clearer. If all the implementations you know about have this timer, it seems like it's a really good idea to have it anyway. But there again, I let specialists talk it over. Best, Emmanuel --001a11426cdeae60f8053c87da93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

see comments inline.

On Tue, Sep 13, 2016 at= 8:43 PM, John G. Scudder <jgs@juniper.net> wrote:
Hi Emmanuel,

Thanks for your review. My questions and comments are in line below.

--John



> Abstract:
> - for clarity, append at the end of last sentence "and for force = a full
> reset"?

Changed (in the source, not yet published as 08 pending this discuss= ion) to "This document also defines a new BGP NOTIFICATION Cease Error= subcode whose effect is to request a full session restart instead of a Gra= ceful Restart. "


Fine wit= h me.
=C2=A0

> - recall that reserved/unspecified fields must be zeroed (and ignored)= ?

While this is a good suggestion as general practice, it seems beyond= the scope of the present draft. If others disagree and think it's OK f= or the present draft to introduce clarifications and modifications to RFC 4= 724 beyond the definition of Notification support, I'd be happy to draf= t some text. But for now, I'd say it's better to hold this for a 47= 24bis.


OK. This= was just a suggestion. However, see next comment below.
=C2=A0

> - in Address family flags: remove "deprecated" specification= text

To be clear, you are suggesting this text should be removed?

"The usage of second most significant bit "N" (which was def= ined in a
previous draft version of this specification) is deprecated. This bit MUST<= br> be advertised as 0 and MUST be ignored upon receipt."

I am inclined to keep it since as it says, a previous version of the draft = did spec such a flag and we have past experience indicating that this can c= ause problems when early implementations operate with more recent ones.=C2= =A0 What's your reason for wanting to remove the text?


I see. B= ut on the other hand, in the long term, you are writing an RFC, and in my o= pinion, it is awkward and confusing to have this kind of text and reference= to an early draft version in an RFC.
One solution could be to re= move the N bit in the figure and recall that as per RFC4724 all reserved bi= ts must be set to zero?
The good side is it could fix your proble= m without referring to "prior versions of the draft".
T= he bad side would be that it is not so great to have exactly the same piece= of spec duplicated from RFC4724.
I'm not sure there is a per= fect solution here.



= =C2=A0
> Section 4:
> - "When a BGP speaker resets its session due to a HOLDTIME expiry= , it
> should generate..."
>=C2=A0 =3D> s/should/SHOULD

I am not inclined to use of the all-caps RFC 2119 language since thi= s is not a new requirement imposed by the current specification, it's m= erely restating an existing requirement. That is, the word "should&quo= t; is being used in its normal English sense. To elaborate, it's my pra= ctice whenever using SHOULD in the RFC 2119 sense, to spend a little effort= considering under what circumstances an implementor might ignore the "= ;SHOULD"=C2=A0 and then discuss those in a "MAY"=C2=A0 claus= e. I think doing that would be outside the scope of this document. If the w= ord "should" causes readers pain, I'm happy to revise the sen= tence in a way that uses a different word.


No stron= g opinion on that. I let specialists talk it over, if needed. Else, let'= ;s do what you propose.
=C2=A0
> Section 4.1:
> - the last paragraph of section 4.2 of RFC4724 states that support for= the
> stale route retain timer is a MAY.
> It seems appropriate to specify upfront that this timer is now a MUST?=

It wasn't our intention to make the timer mandatory. Is there a = reason you think it has to be? (As a practical matter, as far as I know all= implementations do support the timer, but I think that's beside the po= int.)


When one= reads the current spec:
on one hand, I understand that you MUST = do something when this timer fires,
on the other hand, in RFC4724= , this timer MAY be used.
So one naturally wonders what happens i= f this timer is not implemented: can it cause problems?
I was thu= s suggesting that making this timer mandatory would be clearer.
I= f all the implementations you know about have this timer, it seems like it&= #39;s a really good idea to have it anyway.
But there again, I le= t specialists talk it over.

Best,

Emmanuel

--001a11426cdeae60f8053c87da93-- From nobody Mon Sep 19 03:31:43 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF18312B11C; Mon, 19 Sep 2016 03:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 6w44dkfsbi0W; Mon, 19 Sep 2016 03:31:40 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) by ietfa.amsl.com (Postfix) with ESMTP id 504D812B2E3; Mon, 19 Sep 2016 03:31:38 -0700 (PDT) Received: from 97e06288.skybroadband.com ([151.224.98.136] helo=[192.168.0.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1blvrM-0006LJ-Ov; Mon, 19 Sep 2016 11:31:37 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <57D1C8C1.6020505@cisco.com> Date: Mon, 19 Sep 2016 11:31:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <627E28A3-CA72-47CF-914B-3DDBC043CBEA@niven-jenkins.co.uk> <57D1C8C1.6020505@cisco.com> To: Anton Smirnov X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, license restriction X-KLMS-AntiPhishing: not scanned, license restriction X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/09/19 04:35:00 #8090441 X-KLMS-AntiVirus-Status: Clean, skipped Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-lisp-ddt@tools.ietf.org, lisp@ietg.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-ddt-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 10:31:43 -0000 Hi Anton, > On 8 Sep 2016, at 21:23, Anton Smirnov wrote: >=20 > Hello Ben, > thanks for your comments (and for very useful list of places in the = document requiring improvements). Authors of the draft have addressed = questions raised in the review and -08 revision of the draft has been = uploaded. Please give another pass to the document; hopefully now it is = more strict in defining intended behavior and easier to read. Great, I will take a look this week and provide any additional comments. Ben >=20 > Anton >=20 >=20 > On 08/02/2016 12:06 PM, Ben Niven-Jenkins wrote: >> 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-lisp-ddt-07.txt >> Reviewer: Ben Niven-Jenkins >> Review Date: 2nd August 2016 >> Intended Status: Experimental >>=20 >>=20 >> Summary: >> I have some minor concerns about this document that I think should be = resolved before publication. >>=20 >> Comments: >> I found the document to be easily readable even though I am not well = versed in LISP. >>=20 >> Minor issues: >> 1) The document appears quite light on RFC2119 language = (MUST/SHOULD). There are probably areas of the protocol specification = that may benefit from more use of RFC2119 language. >>=20 >> To give one example: Section 7.3.2 says "this Map-Reply will indicate = the least-specific XEID-prefix matching the requested XEID for which no = delegations exist and will have a TTL value of 15 minutes.=E2=80=9D is = that really a =E2=80=9CSHOULD [or MUST?] have a TTL value of 15 = minutes=E2=80=9D? >>=20 >> 2) In a few places the document refers to a =E2=80=9Cproxy Map-Reply = service=E2=80=9D without really explaining what it is. A description in = the terminology section would help, or a reference to another document = that defines the term. >>=20 >>=20 >> HTH >> Ben >>=20 >>=20 From nobody Mon Sep 19 08:57:21 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7352F12B4A5; Mon, 19 Sep 2016 08:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_HTML_ATTACH=0.01] 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 wOM1SG6HZkOC; Mon, 19 Sep 2016 08:57:10 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCA812B46D; Mon, 19 Sep 2016 08:55:04 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id oz2so45335346pac.2; Mon, 19 Sep 2016 08:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=PB+eTparWnoZlMg5Y52rkU+qIXvWYxlCuY1aUDsdbDk=; b=t16Hh3BiJqTnciihMfJri5zXkLc4o6nxC198NN/vjNcKeQLSt+S/+9qftzzunqMxci SUdgcuPnh6m5IkxEX8UCj6D6k8nFGg3urynJl3wcdnB6+HVRnJfimIIl18OTXBLwCOaD vLl2xlUQsOPsUxoIjgUc0/LAnpEoe4OpbruUOjL6XG5w8Sp6P7JDcw/EeShLTU+UrUrZ A3oIP8Z5pEL2DlxMAH2uZ1TU/KIXkq4m2yqeFVoYhUMLR6QOPLVHcA6KqEeD2JhHQ+EI RLH3BkVuxRt3Fx9bhYEYqw1RhIn45jGpFQW7Fa9CXmLPpmzGuT889AXfIoMRBXiCW0Ft 1qAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=PB+eTparWnoZlMg5Y52rkU+qIXvWYxlCuY1aUDsdbDk=; b=VIHK9LYZnam6Bx4iXrRNM1iy/Eo6RYEtJimbtIlGBSRxy9LHDBv31aGB3fC6xLaiV4 RTNPM/iACrTr8xFSCVzCvnbXVXGeG5lBrVJAur+Z3CKu1m+b1wd1bzK7LHyIepksKdpc KaVPcsa5s4n5g3w8esYcZUrsSknY/ndCp7yUnUDD4z2aQuBAko3yWe2UhCo/jRzP6Fi7 hYD028LeNpjDicEYIZFY5QGZx2bdo/lBj1wvho+6hwqQ6Tei+1UQlxTNvDFtBqMWVjnt 7p3Ea+IV35NElD7/o89e+0Sa36+xI3AWUCnEcPIHNtbSfdcrzkXdNBnNwxB9GvQ+m2qf f5Sw== X-Gm-Message-State: AE9vXwPD3iIzpRNjvsdKki0wsQgXmRzDbwvthzsyVULcoL/vLVYkpn1vH7PYKLjlIvj8Rg== X-Received: by 10.66.120.69 with SMTP id la5mr37858718pab.65.1474300504350; Mon, 19 Sep 2016 08:55:04 -0700 (PDT) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id e1sm32669087pap.11.2016.09.19.08.54.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 08:55:02 -0700 (PDT) Content-Type: multipart/mixed; boundary="Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 19 Sep 2016 08:54:55 -0700 Message-Id: <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> To: Stig Venaas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, Dino Farinacci , LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 15:57:19 -0000 --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 9, 2016, at 4:15 PM, Stig Venaas wrote: >=20 >>> In section 3 we have this paragraph: >>>=20 >>> The Address Family AFI definitions from [AFI] only allocate code- >>> points for the AFI value itself. The length of the address or = entity >>> that follows is not defined and is implied based on conventional >>> experience. Where the LISP protocol uses LISP Canonical Addresses >>> specifically, the address length definitions will be in this >>> specification and take precedent over any other specification. >>>=20 >>> I'm not sure what conventional experience means. Please try to find = a >>=20 >> Well like I said above, the AFI values defined in the AFI document = are just type values and there is no length defined. So =E2=80=9Cconventio= nal wisdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we = know what follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >=20 > In theory there should be standards/documents specifying this for each > of the address types, and maybe could write that people should see the > respective standards or something. I don't know if this exists for all > the types though. It does not. But how about I promise you that when there is a new = use-case for a specific AFI, we=E2=80=99ll make sure that the AFI and = its length are defined in that use-case document. Like I said, we have this for AFI=3D17 already. So I have already set an = example. >> better way to say it. Regarding the last sentence, what if a you want >>> to define new LCAF encodings in the future? Is it good to say that = this >>> specification takes precedent over any other? >>=20 >> LCAF encodings and definitions do not change the length of an AFI = encoded address. So I am not sure what you mean. >=20 > The last sentence says "Where the LISP protocol uses LISP Canonical > Addresses specifically, the address length definitions will be in this > specification and take precedent over any other specification.". What > if you in the future would like to write a separate specification that > defines additional LISP Canonical address formats? Okay, I have clarified that new LCAFs that are defined in other = documents will specify length and formatting definitions. >> In section 3 we have this paragraph: >>>=20 >>> Length: this 16-bit field is in units of bytes and covers all of = the >>> LISP Canonical Address payload, starting and including the byte >>> after the Length field. So any LCAF encoded address will have a >>> minimum length of 8 bytes when the Length field is 0. The 8 = bytes >>> include the AFI, Flags, Type, Reserved, and Length fields. When >>> the AFI is not next to encoded address in a control message, = then >>> the encoded address will have a minimum length of 6 bytes when = the >>> Length field is 0. The 6 bytes include the Flags, Type, = Reserved, >>> and Length fields. >>>=20 >>> Can you phrase this differently? First it says that any LCAF encoded >>=20 >> No not really. It is precise up to the sentence =E2=80=9CWhen the AFI = is not ..=E2=80=9D. >>=20 >>> address has a minimum length of 8, but then it goes on to say how it >>> sometimes is only 6. I understand what you're trying to say, but = there >>> may be a better way of stating it. >>=20 >> This special case is for some LISP control-messages where the AFI is = another place in the message but the address is somewhere else. Rather = than have the AFI appear twice, the LCAF length needs to be different. >>=20 >> The length field always includes the entire contiguous set of LCAF = bytes including type, flags, length field, etc. >>=20 >> The language is precise and accurate. Let me know how you think = stating what I did in this comment response can be put in without = writing a lot of text about a special case. >=20 > The problem I see is that first you write "So any LCAF encoded address > will have a minimum length of 8 bytes when the Length field is 0." and > then you write "then the encoded address will have a minimum length of > 6 bytes when the Length field is 0." I understand what you mean, but I > feel this is a bit confusing. >=20 > Maybe you could say something like: >=20 > When including the AFI, an LCAF encoded address will have a minimum > length of 8 bytes when the Length field is 0. Or start by saying that > the minimal length is 6, and then say that it will then be 8 when the > AFI is included. Changed to add your suggestion. Thanks. >>> Section 4.10 >>> In this section there are several examples of using the AFI List = Type, >>> but I miss a general definition. It appears that there can be a = variable >>> number of AFIs in the list. Any number > 0? It might be useful to = have >>=20 >> Yes, a variable number. >=20 > How about adding a few lines of text to 4.10 saying that you can have > a variable number etc., explaining briefly what the general format is. > And then say that what follows are examples? Done. > Section 4.10.3 >>> Isn't it unusual to include the 0 termination? Since you know the >>> length it is not really needed. When parsing one will need to check >>> the length either way, what should one do it the string accidentally >>> is not 0-terminated? >>=20 >> Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate = the string. But the length field will imply it. However, I wrote the = =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is = used (not only in a LCAF but by itself), how to terminate the string. I = could include that reference, but that draft is not a working group = document. >>=20 >> So please advise. >=20 > Currently it says: >=20 > Length value n: length in bytes AFI=3D17 field and the = null-terminated > ASCII string (the last byte of 0 is included). >=20 > It might make sense to 0 terminate the DN in some cases, but at least > here we know the string length from the value of n, so I think it > would be better to drop it here. And as I mentioned, you cannot rely > on the 0 for parsing, to be on the safe side you would use n anyway. You want to terminate the string in all cases. Because there are cases = where AFI=3D17 is not used inside an LCAF encoding. And where there is = no length to convey the string length. And the Distinguished-Name = use-case Internet Draft specs this for both LCAF and non-LCAF = applications. >>> Section 7 >>> It looks like the table in the IANA considerations doesn't include = all >>> the types defined in this document. >>=20 >> That was done intentionally. The ones that are experimental are not = in this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. >=20 > I think it's still useful. If someone sees the type used, they can > look it up in the registry. It also helps avoid that someone perhaps > tries to reuse one of these types in new documents. If you really want > to use one of the code points for something else in the future, a new > document could always update the registry. Did Luigi=E2=80=99s response satisfy your comment? > BTW, it also makes me wonder if it is worth reserving any LCAF types > for experiments. The space is large enough for FCFS.=20 > Regards, > Stig See new version enclosed. Let me know when I can post it if you like the = changes. Thanks again, Dino --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Disposition: attachment; filename=lcaf-rfcdiff.html Content-Type: text/html; name="lcaf-rfcdiff.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-lisp-lcaf-14.txt - = draft-ietf-lisp-lcaf-15.txt=20 =20 =20 =20 =20 =20 =20= = = = = =
< draft-ietf-lisp-lcaf-14.txt  =  draft-ietf-lisp-lcaf-15.txt >
=
Network Working = Group D. Farinacci = Network Working Group = D. Farinacci
Internet-Draft = lispers.net Internet-Draft = lispers.net
Intended status: = Experimental D. Meyer = Intended status: Experimental = D. Meyer
Expires: January 20, 2017 = Brocade Expires: March 23, 2017 = Brocade
= J. Snijders = J. Snijders
= NTT Communications = NTT Communications
= = July 19, 2016 = September 19, 2016
=
= LISP Canonical Address Format (LCAF) = LISP Canonical Address Format (LCAF)
= draft-ietf-lisp-lcaf-14 = = draft-ietf-lisp-lcaf-15
=
Abstract = Abstract
=
This draft = defines a canonical address format encoding used in LISP = This draft defines a canonical address = format encoding used in LISP
control = messages and in the encoding of lookup keys for the LISP = control messages and in the encoding of = lookup keys for the LISP
Mapping = Database System. Mapping Database = System.
=
Requirements = Language Requirements Language
=
The key words = "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",
=
skipping to = change at = page 1, line 41 =C2=B6 = skipping to change at page 1, line 41 =C2=B6
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
Task Force = (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also = distribute
working = documents as Internet-Drafts. The list of current Internet- = working documents as Internet-Drafts. The = list of current Internet-
Drafts is at = http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
=
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
and may be = updated, replaced, or obsoleted by other documents at any = and may be updated, replaced, or obsoleted = by other documents at any
time. It is = inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as = reference
material or to = cite them other than as "work in progress." material or to cite them other than as "work in = progress."
=
This = Internet-Draft will expire on January 20, = 2017. This Internet-Draft will = expire on March 23, 2017.
=
Copyright = Notice Copyright Notice
=
Copyright (c) = 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons = identified as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
=
skipping to = change at = page 2, line 23 =C2=B6 = skipping to change at page 2, line 23 =C2=B6
=
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 1. Introduction . . . . . . . . = . . . . . . . . . . . . . . . . 3
2. Definition = of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . = . . . . . . 4
3. LISP = Canonical Address Format Encodings . . . . . . . . . . . 5 = 3. LISP Canonical Address Format Encodings = . . . . . . . . . . . 5
4. LISP = Canonical Address Applications . . . . . . . . . . . . . 7 = 4. LISP Canonical Address Applications . . = . . . . . . . . . . . 7
4.1. = Segmentation using LISP . . . . . . . . . . . . . . . . . 7 = 4.1. Segmentation using LISP . . . . . . = . . . . . . . . . . . 7
4.2. = Carrying AS Numbers in the Mapping Database . . . . . . . 9 = 4.2. Carrying AS Numbers in the Mapping = Database . . . . . . . 9
4.3. = Assigning Geo Coordinates to Locator Addresses . . . . . 10 = 4.3. Assigning Geo Coordinates to Locator = Addresses . . . . . 10
4.4. NAT = Traversal Scenarios . . . . . . . . . . . . . . . . . 12 = 4.4. NAT Traversal Scenarios . . . . . . = . . . . . . . . . . . 12
4.5. = Multicast Group Membership Information . . . . . . . . . 14 = 4.5. Multicast Group Membership = Information . . . . . . . . . 14
4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 15 4.6. = Traffic Engineering using Re-encapsulating Tunnels . . . 16
4.7. = Storing Security Data in the Mapping Database . . . . . . 17 = 4.7. Storing Security Data in the Mapping = Database . . . . . . 17
4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 18 4.8. = Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19
4.9. = Replication List Entries for Multicast Forwarding . . . . 20 4.9. = Replication List Entries for Multicast Forwarding . . . . 21
4.10. = Applications for AFI List Type . . . . . . . . . . . . . 21 4.10. = Applications for AFI List Type . . . . . . . . . . . . . 22
4.10.1. = Binding IPv4 and IPv6 Addresses . . . . . . . . . . 21 = 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22
4.10.2. = Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 22 = 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23
4.10.3. = ASCII Names in the Mapping Database . . . . . . . . 23 = 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24
4.10.4. = Using Recursive LISP Canonical Address Encodings . . 24 = 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25
4.10.5. = Compatibility Mode Use Case . . . . . . . . . . . . 25 = 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26
5. = Experimental LISP Canonical Address Applications . . . . . . 26 5. = Experimental LISP Canonical Address Applications . . . . . . 27
5.1. = Convey Application Specific Data . . . . . . . . . . . . 26 5.1. = Convey Application Specific Data . . . . . . . . . . . . 27
5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 27 5.2. = Generic Database Mapping Lookups . . . . . . . . . . . . 28
5.3. PETR = Admission Control Functionality . . . . . . . . . . 29 5.3. = PETR Admission Control Functionality . . . . . . . . . . 30
5.4. Data = Model Encoding . . . . . . . . . . . . . . . . . . . 30 5.4. = Data Model Encoding . . . . . . . . . . . . . . . . . . . 31
5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 31 5.5. = Encoding Key/Value Address Pairs . . . . . . . . . . . . 32
5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 32 5.6. = Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33
6. Security = Considerations . . . . . . . . . . . . . . . . . . . 34 6. = Security Considerations . . . . . . . . . . . . . . . . . . . 36
7. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. = IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. = References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. = Normative References . . . . . . . . . . . . . . . . . . 35 8.1. = Normative References . . . . . . . . . . . . . . . . . . 37
8.2. = Informative References . . . . . . . . . . . . . . . . . 36 8.2. = Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. = Acknowledgments . . . . . . . . . . . . . . . . . . 37 = Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. = Document Change Log . . . . . . . . . . . . . . . . 38 = Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40
B.1. = Changes to draft-ietf-lisp-lcaf-14.txt . = . . . . . . . . 38 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . = 40
B.2. = Changes to draft-ietf-lisp-lcaf-13.txt . = . . . . . . . . 38 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . = 40
B.3. = Changes to draft-ietf-lisp-lcaf-12.txt . = . . . . . . . . 38 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . = 40
B.4. = Changes to draft-ietf-lisp-lcaf-11.txt . = . . . . . . . . 38 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . = 40
B.5. = Changes to draft-ietf-lisp-lcaf-10.txt . = . . . . . . . . 38 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . = 40
B.6. = Changes to draft-ietf-lisp-lcaf-09.txt . = . . . . . . . . 39 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . = 41
B.7. = Changes to draft-ietf-lisp-lcaf-08.txt . = . . . . . . . . 39 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . = 41
B.8. = Changes to draft-ietf-lisp-lcaf-07.txt . = . . . . . . . . 39 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . = 41
B.9. = Changes to draft-ietf-lisp-lcaf-06.txt . = . . . . . . . . 39 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . = 41
B.10. = Changes to draft-ietf-lisp-lcaf-05.txt . = . . . . . . . . 39 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . = 41
B.11. = Changes to draft-ietf-lisp-lcaf-04.txt . = . . . . . . . . 39 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . = 41
B.12. = Changes to draft-ietf-lisp-lcaf-03.txt . = . . . . . . . . 40 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . = 42
B.13. = Changes to draft-ietf-lisp-lcaf-02.txt . = . . . . . . . . 40 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . = 42
B.14. = Changes to draft-ietf-lisp-lcaf-01.txt . = . . . . . . . . 40 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . = 42
B.15. = Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 40 B.15. = Changes to draft-ietf-lisp-lcaf-01.txt . . . . . = . . . . 42
Authors' = Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 B.16. Changes to = draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42
= Authors' Addresses . . . . . . . . . . . . = . . . . . . . . . . . 43
=
1. = Introduction 1. Introduction
=
The LISP = architecture and protocols [RFC6830] introduces two new = The LISP architecture and protocols = [RFC6830] introduces two new
numbering = spaces, Endpoint Identifiers (EIDs) and Routing Locators = numbering spaces, Endpoint Identifiers = (EIDs) and Routing Locators
(RLOCs). To = provide flexibility for current and future applications, = (RLOCs). To provide flexibility for current = and future applications,
these values = can be encoded in LISP control messages using a general = these values can be encoded in LISP control = messages using a general
syntax that = includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), = length, and
value = fields. value fields.
=
=
skipping to = change at = page 4, line 28 =C2=B6 = skipping to change at page 4, line 28 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
This document = describes the currently-defined AFIs the LISP protocol This document describes the currently-defined AFIs = the LISP protocol
uses along = with their encodings and introduces the LISP Canonical uses along with their encodings and introduces the = LISP Canonical
Address Format = (LCAF) that can be used to define the LISP-specific Address Format (LCAF) that can be used to define the = LISP-specific
encodings for = arbitrary AFI values. encodings for = arbitrary AFI values.
=
2. Definition of = Terms 2. Definition of Terms
=
Address Family = Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to = describe an address
encoding = in a packet. There is an address family = currently encoding in a = packet. Address families are defined for = IPv4 and
defined = for IPv4 or IPv6 addresses. See [AFI] and = [RFC3232] for = IPv6. See [AFI] and [RFC3232] for details. The reserved = AFI
details. = The reserved AFI value of 0 is used in this value of 0 is used in this specification to = indicate an
= specification to indicate an unspecified encoded address where = the unspecified encoded address = where the length of the address is 0
length of = the address is 0 bytes following the 16-bit AFI value of = bytes following the 16-bit AFI value of = 0.
= 0.
=
Unspecified = Address Format: Unspecified Address = Format:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 0 | <nothing follows AFI=3D0> | = | AFI =3D 0 | = <nothing follows AFI=3D0> |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Endpoint ID = (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value = Endpoint ID (EID): a 32-bit (for IPv4) or = 128-bit (for IPv6) value
=
skipping to = change at = page 5, line 26 =C2=B6 = skipping to change at page 5, line 26 =C2=B6
=
IANA has = assigned AFI value 16387 (0x4003) to the LISP architecture = IANA has assigned AFI value 16387 (0x4003) = to the LISP architecture
and protocols. = This specification defines the encoding format of the and protocols. This specification defines the = encoding format of the
LISP Canonical = Address (LCA). This section defines all types for LISP Canonical Address (LCA). This section defines = all types for
which an = initial allocation in the LISP-LCAF registry is requested. = which an initial allocation in the LISP-LCAF = registry is requested.
See IANA = Considerations section for the complete list of such types. = See IANA Considerations section for the = complete list of such types.
=
The Address = Family AFI definitions from [AFI] only allocate code- The Address Family AFI definitions from [AFI] only = allocate code-
points for the = AFI value itself. The length of the address or entity points for the AFI value itself. The length of the = address or entity
that follows = is not defined and is implied based on conventional that follows is not defined and is implied based on = conventional
experience. = Where the LISP protocol uses LISP Canonical Addresses experience. When the = LISP protocol uses LCAF definitions from = this
specifically, the address length definitions will be in this = document, the = AFI-based address lengths are specified in this
specification and take precedent over any other = specification. document. When new LCAF = definitions are defined in other use-case
= documents, the = AFI-based address lengths for any new AFI encoded
= addresses are = specified in those documents.
=
The first 6 = bytes of an LISP Canonical Address are followed by a The first 6 bytes of an LISP Canonical Address are = followed by a
variable = number of fields of variable length: = variable number of fields of variable length:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = | Rsvd2 | Length | | Type | Rsvd2 | Length = |
=
skipping to = change at = page 6, line 34 =C2=B6 = skipping to change at page 6, line 36 =C2=B6
Type 12: = Source/Dest Key Type Type 12: = Source/Dest Key Type
=
Type 13: = Replication List Entry Type Type = 13: Replication List Entry Type
=
Type 14: = JSON Data Model Type Type 14: = JSON Data Model Type
=
Type 15: = Key/Value Address Pair Type Type = 15: Key/Value Address Pair Type
=
Type 16: = Encapsulation Format Type Type = 16: Encapsulation Format Type
=
Rsvd2: this = 8-bit field is reserved for future use and MUST be Rsvd2: this LCAF Type = dependent 8-bit field is reserved for future
= transmitted as 0 and ignored on receipt. use and MUST be transmitted as 0 and ignored on = receipt. See
= specific LCAF = Type for specific bits not reserved.
=
Length: this = 16-bit field is in units of bytes and covers all of the = Length: this 16-bit field is in units of = bytes and covers all of the
LISP = Canonical Address payload, starting and including the byte = LISP Canonical Address payload, starting = and including the byte
after the = Length field. So any LCAF encoded address = will have a after the Length = field. When including the AFI, an LCAF = encoded
minimum = length of 8 bytes when the Length field is 0. The 8 bytes = address will have a minimum length of 8 = bytes when the Length
include = the AFI, Flags, Type, Reserved, and Length fields. When = field is 0. The 8 bytes include the = AFI, Flags, Type, Reserved,
the AFI = is not next to encoded address in a control message, then = and Length fields. When the AFI is not = next to encoded address in
the = encoded address will have a minimum length of 6 bytes when the = a control message, then the encoded = address will have a minimum
Length = field is 0. The 6 bytes include the Flags, Type, Reserved, = length of 6 bytes when the Length field = is 0. The 6 bytes include
and = Length fields. the Flags, Type, = Reserved, and Length fields.
=
[RFC6830] = states RLOC records are sorted when encoded in control [RFC6830] states RLOC records are sorted when encoded = in control
messages so = the locator-set has consistent order across all xTRs for = messages so the locator-set has consistent = order across all xTRs for
a given EID. = The sort order is based on sort-key {afi, RLOC- a given EID. The sort order is based on sort-key = {afi, RLOC-
address}. When = an RLOC is LCAF encoded, the sort-key is {afi, LCAF- address}. When an RLOC is LCAF encoded, the sort-key = is {afi, LCAF-
Type}. = Therefore, when a locator-set has a mix of AFI records and = Type}. Therefore, when a locator-set has a = mix of AFI records and
LCAF = records, all LCAF records will appear after all = the AFI records. LCAF = records, they are ordered from smallest to = largest AFI value.
=
4. LISP = Canonical Address Applications 4. = LISP Canonical Address Applications
=
4.1. = Segmentation using LISP 4.1. = Segmentation using LISP
=
When multiple = organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are = using private
addresses = [RFC1918] as EID-prefixes, their address spaces must remain = addresses [RFC1918] as EID-prefixes, their = address spaces must remain
segregated due = to possible address duplication. An Instance ID in segregated due to possible address duplication. An = Instance ID in
the address = encoding can aid in making the entire AFI based address = the address encoding can aid in making the = entire AFI based address
= unique. unique.
=
skipping to = change at = page 13, line 12 =C2=B6 = skipping to change at page 13, line = 12 =C2=B6
MS RLOC = Address: this is the address of the Map-Server used in the = MS RLOC Address: this is the address of the = Map-Server used in the
destination = RLOC of a packet that has flowed through a NAT device. destination RLOC of a packet that has flowed = through a NAT device.
=
Private ETR = RLOC Address: this is an address known to be a private = Private ETR RLOC Address: this is an = address known to be a private
address = inserted in this LCAF format by a LISP router that resides = address inserted in this LCAF format by a = LISP router that resides
on the = private side of a NAT device. on = the private side of a NAT device.
=
RTR RLOC = Address: this is an encapsulation address used by an ITR or = RTR RLOC Address: this is an encapsulation = address used by an ITR or
PITR which = resides behind a NAT device. This address is known to PITR which resides behind a NAT device. This = address is known to
have state = in a NAT device so packets can flow from it to the LISP = have state in a NAT device so packets can = flow from it to the LISP
ETR = behind the NAT. There can be one or more NAT Tunnel Router = ETR behind the NAT. There can be one or = more NAT Reencapsulating
(NTR) [I-D.ermagan-lisp-nat-traversal] addresses = supplied in these Tunnel Router = (RTR) [I-D.ermagan-lisp-nat-traversal] = addresses
set of = fields. The number of NTRs encoded is = determined by the supplied in = these set of fields. The number of RTRs = encoded is
LCAF = length field. When there are no NTRs = supplied, the NTR determined by the LCAF length field. When there = are no RTRs
fields = can be omitted and reflected by the LCAF length field or an = supplied, the RTR fields can be omitted and reflected by the = LCAF
AFI of 0 = can be used to indicate zero NTRs = encoded. length field or an AFI = of 0 can be used to indicate zero RTRs
= encoded.
=
Usage: This = encoding can be used in Info-Request and Info-Reply Usage: This encoding can be used in Info-Request and = Info-Reply
messages. The = mapping system does not store this information. The messages. The mapping system does not store this = information. The
information is = used by an xTR and Map-Server to convey private and information is used by an xTR and Map-Server to = convey private and
public address = information when traversing NAT and firewall devices. public address information when traversing NAT and = firewall devices.
=
4.5. Multicast = Group Membership Information 4.5. = Multicast Group Membership Information
=
Multicast = group information can be published in the mapping database. = Multicast group information can be published = in the mapping database.
So a lookup on = an group address EID can return a replication list of So a lookup on an group address EID can return a = replication list of
=
skipping to = change at = page 15, line 11 =C2=B6 = skipping to change at page 15, line = 11 =C2=B6
of = (Instance-ID, S-prefix, G-prefix). = of (Instance-ID, S-prefix, G-prefix).
=
Source = MaskLen: the mask length of the source prefix that follows. = Source MaskLen: the mask length of the = source prefix that follows.
=
Group MaskLen: = the mask length of the group prefix that follows. Group MaskLen: the mask length of the group prefix = that follows.
=
AFI =3D x: x = can be any AFI value from [AFI]. When a specific AFI has = AFI =3D x: x can be any AFI value from = [AFI]. When a specific AFI has
its own = encoding of a multicast address, this field must be either = its own encoding of a multicast address, = this field must be either
a group = address or a broadcast address. = a group address or a broadcast address.
=
= Source/Subnet = Address is the source address or prefix for encoding a
= (S,G) multicast = entry.
=
= Group Address is = the group address or group prefix for encoding
= (S,G) or (*,G) = multicast entries.
= =
Usage: This = encoding can be used in EID records in Map-Requests, Map- = Usage: This encoding can be used in EID = records in Map-Requests, Map-
Replies, = Map-Registers, and Map-Notify messages. When LISP-DDT Replies, Map-Registers, and Map-Notify messages. = When LISP-DDT
= [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, = extended [I-D.ietf-lisp-ddt] is = used as the mapping system mechanism, extended
EIDs are used = in Map-Referral messages. EIDs are = used in Map-Referral messages.
=
4.6. Traffic = Engineering using Re-encapsulating Tunnels 4.6. Traffic Engineering using Re-encapsulating = Tunnels
=
For a given = EID lookup into the mapping database, this LCAF format For a given EID lookup into the mapping database, = this LCAF format
can be = returned to provide a list of locators in an explicit re- = can be returned to provide a list of = locators in an explicit re-
encapsulation = path. See [I-D.farinacci-lisp-te] for details. encapsulation path. See [I-D.farinacci-lisp-te] for = details.
=
skipping to = change at = page 16, line 25 =C2=B6 = skipping to change at page 16, line = 31 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop 1 ... | | Reencap Hop 1 ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Rsvd3 |L|P|S| AFI =3D x | = | Rsvd3 |L|P|S| = AFI =3D x |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = Reencap Hop k ... | | Reencap Hop k ... = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Lookup bit = (L): this is the Lookup bit used to indicate to the user = Lookup bit (L): this is the Lookup bit used = to indicate to the user
of the ELP = to not use this address for encapsulation but to look of the ELP to not use this address for = encapsulation but to look
it up in = the mapping database system to obtain an encapsulating it up in the mapping database system to obtain an = encapsulating
RLOC = address. RLOC address.
=
RLOC-Probe bit = (P): this is the RLOC-probe bit which means the RLOC-Probe bit (P): this is the RLOC-probe bit which = means the
Reencap Hop = allows RLOC-probe messages to be sent to it. When the Reencap Hop allows RLOC-probe messages to be sent = to it. When the
R-bit is = set to 0, RLOC-probes must not be sent. When a Reencap = R-bit is set to 0, RLOC-probes must not = be sent. When a Reencap
Hop is an = anycast address then multiple physical Reencap Hops are = Hop is an anycast address then multiple = physical Reencap Hops are
using the = same RLOC address. In this case, RLOC-probes are not using the same RLOC address. In this case, = RLOC-probes are not
=
skipping = to change at page 17, line = 35 =C2=B6 = skipping to change at page 18, line = 29 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Locator Address ... | | AFI =3D x | Locator = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that start with the Key Length value n: length in bytes of fields that start = with the Key
Material = field. Material field.
=
Key Count: = the Key Count field declares the number of Key sections = Key Count: the Key Count field declares the = number of Key sections
included in = this LCAF. included in this = LCAF.
=
= Rsvd3: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
Key Algorithm: = the Algorithm field identifies the key's Key Algorithm: the Algorithm field identifies the = key's
= cryptographic algorithm and specifies the format of the Public = Key cryptographic algorithm and = specifies the format of the Public Key
= field. field.
=
= Rsvd4: this field = is reserved for future use and MUST be transmitted
= as 0 and ignored = on receipt.
= =
R bit: this = is the revoke bit and, if set, it specifies that this R bit: this is the revoke bit and, if set, it = specifies that this
Key is = being Revoked. Key is being = Revoked.
=
Key Length: = this field determines the length in bytes of the Key Key Length: this field determines the length in = bytes of the Key
Material = field. Material field.
=
Key Material: = the Key Material field stores the key material. The Key Material: the Key Material field stores the key = material. The
format of = the key material stored depends on the Key Algorithm format of the key material stored depends on the = Key Algorithm
= field. field.
=
=
skipping = to change at page 21, line = 10 =C2=B6 = skipping to change at page 22, line = 10 =C2=B6
Reply = message. Reply message.
=
Usage: This = encoding can be used in RLOC records in Map-Requests, Usage: This encoding can be used in RLOC records in = Map-Requests,
Map-Replies, = Map-Registers, and Map-Notify messages. = Map-Replies, Map-Registers, and Map-Notify messages.
=
4.10. = Applications for AFI List Type 4.10. = Applications for AFI List Type
=
4.10.1. Binding = IPv4 and IPv6 Addresses 4.10.1. = Binding IPv4 and IPv6 Addresses
=
When header = translation between IPv4 and IPv6 is desirable a LISP When header translation between IPv4 and IPv6 is = desirable a LISP
Canonical = Address can use the AFI List Type to carry multiple AFIs in Canonical Address can use the AFI List Type to carry = a variable
one LCAF = AFI. number = of AFIs in one LCAF AFI.
=
Address = Binding LISP Canonical Address Format: = Address Binding LISP Canonical Address Format:
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D 1 = | Rsvd2 | 2 + 4 + 2 + 16 | | Type =3D 1 | Rsvd2 | 2 + 4 + 2 = + 16 |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
skipping = to change at page 28, line = 5 =C2=B6 = skipping to change at page 29, line = 5 =C2=B6
| Type =3D 6 = | Rsvd2 | 3 + n | | Type =3D 6 | Rsvd2 | 3 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Field = Num | Key Wildcard Fields | Key . . . | | Key Field Num | Key Wildcard Fields | = Key . . . |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = . . . Key | | . . . Key = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of the type's payload. The value n = Length value n: length in bytes of the = type's payload. The value n
is the = number of bytes that follow this Length field. is the number of bytes that follow this Length = field.
=
Key Field = Num: the number of fields (minus 1) the = key can be broken Key Field Num: the value of = this field is the the number of "Key"
up into. = The width of the fields are fixed length. = So for a key = sub-fields minus 1, the "Key" = field can be broken up into. So = if
size of 8 = bytes, with a Key Field Num of 4 allows 4 = fields of 2 this field has a value of = 0, there is 1 sub-field in the "Key".
bytes in = length. Allowing for a reasonable number of 16 field The width of the sub-fields are fixed length. So for a key = size
= separators, valid values range from 0 to 15. of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2
= bytes each = in length. Allowing for a reasonable number of 16 sub-
= field separators, valid values range = from 0 to 15.
=
Key Wildcard = Fields: describes which fields in the key are not used = Key Wildcard Fields: describes which fields = in the key are not used
as part of = the key lookup. This wildcard encoding is a bitfield. as part of the key lookup. This wildcard encoding = is a bitfield.
Each bit is = a don't-care bit for a corresponding field in the key. Each bit is a don't-care bit for a corresponding = field in the key.
Bit 0 (the = low-order bit) in this bitfield corresponds the first Bit 0 (the low-order bit) in this bitfield = corresponds the first
field, = right-justified in the key, bit 1 the = second field, and so field, = the low-order field in the key, bit 1 the = second field, and
on. When = a bit is set in the bitfield it is a don't-care bit and = so on. When a bit is set in the = bitfield it is a don't-care bit
should = not be considered as part of the database lookup. When the = and should not be considered as part of = the database lookup. When
entire = 16-bits is set to 0, then all bits of the key are used for = the entire 16-bits is set to 0, then all = bits of the key are used
the = database lookup. for the = database lookup.
=
Key: the = variable length key used to do a LISP Database Mapping Key: the variable length key used to do a LISP = Database Mapping
lookup. = The length of the key is the value n (shown = above) minus lookup. = The length of the key is the value n (as shown = above).
3.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.3. PETR = Admission Control Functionality 5.3. = PETR Admission Control Functionality
=
When a public = PETR device wants to verify who is encapsulating to it, = When a public PETR device wants to verify = who is encapsulating to it,
it can check = for a specific nonce value in the LISP encapsulated it can check for a specific nonce value in the LISP = encapsulated
packet. To = convey the nonce to admitted ITRs or PITRs, this LCAF packet. To convey the nonce to admitted ITRs or = PITRs, this LCAF
format is used = in a Map-Register or Map-Reply locator-record. format is used in a Map-Register or Map-Reply = locator-record.
=
skipping = to change at page 30, line = 24 =C2=B6 = skipping to change at page 31, line = 24 =C2=B6
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 14 | Rsvd2 |B| 2 + n | | Type =3D 14 | Rsvd2 |B| 2 + n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = JSON length | JSON binary/text encoding ... | | JSON length | JSON binary/text = encoding ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Optional Address ... | | AFI =3D x | Optional = Address ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. = Length value n: length in bytes of the = fields that follow the "JSON
= length" = field.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
B bit: = indicates that the JSON field is binary encoded according to = B bit: indicates that the JSON field is = binary encoded according to
= [JSON-BINARY] when the bit is set to 1. Otherwise the encoding = is [JSON-BINARY] when the bit is = set to 1. Otherwise the encoding is
based on = text encoding according to [RFC7159]. = based on text encoding according to [RFC7159].
=
JSON length: = length in octets of the following 'JSON binary/text JSON length: length in octets of the following 'JSON = binary/text
encoding' = field. encoding' field.
=
=
skipping = to change at page 31, line = 26 =C2=B6 = skipping to change at page 32, line = 26 =C2=B6
=
0 = 1 2 3 0 1 2 = 3
0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D 16387 | Rsvd1 | Flags | = | AFI =3D 16387 | = Rsvd1 | Flags |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =3D = 15 | Rsvd2 | n | | Type =3D 15 | Rsvd2 | n = |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as Key ... | | AFI =3D x | Address as = Key ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| = AFI =3D x | Address as = Value ... | | AFI = =3D y | Address as Value = ... |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Length value = n: length in bytes of fields that follow. Length value n: length in bytes of fields that = follow.
=
Rsvd{1,2}: = must be set to zero and ignore on receipt. Rsvd{1,2}: must be set to zero and ignore on = receipt.
=
AFI =3D x: = x can be any AFI value from [AFI]. A specific AFI has = its AFI =3D x: x is the "Address as Key" AFI that can have any value from
own = encoding of either a unicast or multicast locator address. = [AFI]. A specific AFI has its own = encoding of either a unicast or
All = RTR/ETR entries for the same level should be combined together = multicast locator address. All RTR/ETR = entries for the same level
by a = Map-Server to avoid searching through the entire multi-level = should be combined together by a = Map-Server to avoid searching
list of = locator entries in a Map-Reply = message. through the entire = multi-level list of locator entries in a Map-
= Reply = message.
=
Address as = Key: this AFI encoded address will be attached with the = Address as Key: this AFI encoded address = will be attached with the
attributes = encoded in "Address as Value" which follows this field. = attributes encoded in "Address as Value" = which follows this field.
=
= AFI =3D y: y is the = "Address of Value" AFI that can have any value
= from [AFI]. A = specific AFI has its own encoding of either a
= unicast or = multicast locator address. All RTR/ETR entries for the
= same level should = be combined together by a Map-Server to avoid
= searching through = the entire multi-level list of locator entries
= in a Map-Reply = message.
= =
Address as = Value: this AFI encoded address will be the attribute Address as Value: this AFI encoded address will be = the attribute
address = that goes along with "Address as Key" which precedes this = address that goes along with "Address as = Key" which precedes this
= field. field.
=
Usage: This is = an experimental type where the usage has not been Usage: This is an experimental type where the usage = has not been
defined = yet. defined yet.
=
5.6. Multiple = Data-Planes 5.6. Multiple = Data-Planes
=
Overlays are = becoming popular in many parts of the network which have = Overlays are becoming popular in many parts = of the network which have
=
skipping = to change at page 36, line = 19 =C2=B6 = skipping to change at page 38, line = 19 =C2=B6
=
= [I-D.coras-lisp-re] = [I-D.coras-lisp-re]
= Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., = Domingo-Pascual, J.,
= Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP = Replication
= Engineering", draft-coras-lisp-re-08 (work in progress), = Engineering", = draft-coras-lisp-re-08 (work in progress),
= November 2015. November = 2015.
=
= [I-D.ermagan-lisp-nat-traversal] = [I-D.ermagan-lisp-nat-traversal]
= Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, = Ermagan, V., Farinacci, D., = Lewis, D., Skriver, J., Maino,
F., = and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for = LISP", draft-ermagan-
= lisp-nat-traversal-10 (work in progress), = February 2016. = lisp-nat-traversal-11 (work in progress), = August 2016.
=
= [I-D.farinacci-lisp-te] = [I-D.farinacci-lisp-te]
= Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Farinacci, D., Kowal, M., and P. Lahiri, = "LISP Traffic
= Engineering Use-Cases", draft-farinacci-lisp-te-10 (work = Engineering Use-Cases", draft-farinacci-lisp-te-11 (work
= in progress), March 2016. = in progress), September 2016.
=
= [I-D.gross-geneve] = [I-D.gross-geneve]
= Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., = Gross, J., Sridhar, T., Garg, P., = Wright, C., Ganga, I.,
= Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: = Agarwal, P., Duda, K., Dutt, D., = and J. Hudson, "Geneve:
= Generic Network Virtualization Encapsulation", draft- Generic Network Virtualization = Encapsulation", draft-
= gross-geneve-02 (work in progress), October 2014. gross-geneve-02 (work in progress), = October 2014.
=
= [I-D.herbert-gue] = [I-D.herbert-gue]
= Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, = "Generic UDP
= Encapsulation", draft-herbert-gue-03 (work in progress), = Encapsulation", = draft-herbert-gue-03 (work in progress),
= March 2015. March = 2015.
=
= [I-D.ietf-lisp-ddt] = [I-D.ietf-lisp-ddt]
= Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, = A., and A.
= Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- = Smirnov, "LISP Delegated Database = Tree", draft-ietf-lisp-
= ddt-07 (work in progress), May = 2016. ddt-08 (work in progress), September 2016.
=
= [I-D.portoles-lisp-eid-mobility] = [I-D.portoles-lisp-eid-mobility]
= Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, = Portoles-Comeras, M., Ashtaputre, = V., Moreno, V., Maino,
F., = and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID = Mobility Using a
= Unified Control Plane", draft-portoles-lisp-eid- Unified Control Plane", = draft-portoles-lisp-eid-
= mobility-00 (work in progress), April 2016. mobility-00 (work in progress), April = 2016.
=
= [I-D.quinn-vxlan-gpe] = [I-D.quinn-vxlan-gpe]
= Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., = Quinn, P., Manur, R., Kreeger, = L., Lewis, D., Maino, F.,
= Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, = Smith, M., Agarwal, P., Yong, L., = Xu, X., Elzur, U., Garg,
=
skipping = to change at page 38, line = 9 =C2=B6 = skipping to change at page 40, line = 9 =C2=B6
Thanks goes to = Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto = Rodriguez-Natal for
suggesting new = LCAF types. suggesting new LCAF = types.
=
Thanks also = goes to Terry Manderson for assistance obtaining a LISP = Thanks also goes to Terry Manderson for = assistance obtaining a LISP
AFI value from = IANA. AFI value from IANA.
=
Appendix B. = Document Change Log Appendix B. = Document Change Log
=
[RFC Editor: = Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on = publication as RFC.]
=
B.1. Changes = to draft-ietf-lisp-lcaf-14.txt B.1. = Changes to draft-ietf-lisp-lcaf-15.txt
=
= o Submitted = September 2016.
=
= o Addressed = comments from Routing Directorate reviewer Stig Venass.
=
= B.2. Changes to = draft-ietf-lisp-lcaf-14.txt
=
o Submitted = July 2016. o Submitted July = 2016.
=
o Fix IDnits = errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, = document
= shepherd. shepherd.
=
B.2. Changes to = draft-ietf-lisp-lcaf-13.txt B.3. Changes to = draft-ietf-lisp-lcaf-13.txt
=
o Submitted = May 2016. o Submitted May = 2016.
=
o Explain the = Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in = length and the
Instance-ID = field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header = is 24-bits.
=
B.3. Changes to = draft-ietf-lisp-lcaf-12.txt B.4. Changes to = draft-ietf-lisp-lcaf-12.txt
=
o Submitted = March 2016. o Submitted March = 2016.
=
o Updated = references and document timer. o = Updated references and document timer.
=
o Removed the = R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast = Info Type LCAF
since = working group decided to not go forward with draft- since working group decided to not go forward with = draft-
= farinacci-lisp-mr-signaling-03.txt in favor of draft- = ietf-lisp- = farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
= signal-free-00.txt. = signal-free-00.txt.
=
B.4. Changes to = draft-ietf-lisp-lcaf-11.txt B.5. Changes to = draft-ietf-lisp-lcaf-11.txt
=
o Submitted = September 2015. o Submitted = September 2015.
=
o Reflecting = comments from Prague LISP working group. o Reflecting comments from Prague LISP working = group.
=
o Readying = document for a LISP LCAF registry, RFC publication, and = o Readying document for a LISP LCAF = registry, RFC publication, and
for new = use-cases that will be defined in the new charter. for new use-cases that will be defined in the new = charter.
=
B.5. Changes to = draft-ietf-lisp-lcaf-10.txt B.6. Changes to = draft-ietf-lisp-lcaf-10.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix = coauthor Job's contact information. = o Fix coauthor Job's contact information.
=
B.6. Changes to = draft-ietf-lisp-lcaf-09.txt B.7. Changes to = draft-ietf-lisp-lcaf-09.txt
=
o Submitted = June 2015. o Submitted June = 2015.
=
o Fix IANA = Considerations section to request a registry to allocate = o Fix IANA Considerations section to = request a registry to allocate
and track = LCAF Type values. and track LCAF = Type values.
=
B.7. Changes to = draft-ietf-lisp-lcaf-08.txt B.8. Changes to = draft-ietf-lisp-lcaf-08.txt
=
o Submitted = April 2015. o Submitted April = 2015.
=
o Comment = from Florin. The Application Data Type length field has a = o Comment from Florin. The Application = Data Type length field has a
typo. The = field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and = not "8 + n".
=
o Fix length = fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using = Recursive LISP
Canonical = Address Encodings", "Generic Database Mapping Lookups", = Canonical Address Encodings", "Generic = Database Mapping Lookups",
and "Data = Model Encoding". and "Data Model = Encoding".
=
B.8. Changes to = draft-ietf-lisp-lcaf-07.txt B.9. Changes to = draft-ietf-lisp-lcaf-07.txt
=
o Submitted = December 2014. o Submitted = December 2014.
=
o Add a new = LCAF Type called "Encapsulation Format" so decapsulating = o Add a new LCAF Type called "Encapsulation = Format" so decapsulating
xTRs can = inform encapsulating xTRs what data-plane encapsulations = xTRs can inform encapsulating xTRs what = data-plane encapsulations
they = support. they support.
=
B.9. Changes to = draft-ietf-lisp-lcaf-06.txt B.10. Changes to = draft-ietf-lisp-lcaf-06.txt
=
o Submitted = October 2014. o Submitted October = 2014.
=
o Make it = clear how sorted RLOC records are done when LCAFs are used = o Make it clear how sorted RLOC records are = done when LCAFs are used
as the RLOC = record. as the RLOC = record.
=
B.10. Changes to = draft-ietf-lisp-lcaf-05.txt B.11. Changes to = draft-ietf-lisp-lcaf-05.txt
=
o Submitted = May 2014. o Submitted May = 2014.
=
o Add a = length field of the JSON payload that can be used for either = o Add a length field of the JSON payload = that can be used for either
binary or = text encoding of JSON data. = binary or text encoding of JSON data.
=
B.11. Changes to = draft-ietf-lisp-lcaf-04.txt B.12. Changes to = draft-ietf-lisp-lcaf-04.txt
=
o Submitted = January 2014. o Submitted January = 2014.
=
o Agreement = among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI = 16-bit field
adjacent to = the address. This will make the encoding consistent adjacent to the address. This will make the = encoding consistent
with all = other LCAF type address encodings. = with all other LCAF type address encodings.
=
B.12. Changes to = draft-ietf-lisp-lcaf-03.txt B.13. Changes to = draft-ietf-lisp-lcaf-03.txt
=
o Submitted = September 2013. o Submitted = September 2013.
=
o Updated = references and author's affilations. = o Updated references and author's affilations.
=
o Added = Instance-ID to the Multicast Info Type so there is relative = o Added Instance-ID to the Multicast Info = Type so there is relative
ease in = parsing (S,G) entries within a VPN. = ease in parsing (S,G) entries within a VPN.
=
o Add port = range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data = LCAF Type.
=
o Add a new = JSON LCAF Type. o Add a new JSON = LCAF Type.
=
o Add Address = Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow = attributes to be attached
to an = address. to an address.
=
B.13. Changes to = draft-ietf-lisp-lcaf-02.txt B.14. Changes to = draft-ietf-lisp-lcaf-02.txt
=
o Submitted = March 2013. o Submitted March = 2013.
=
o Added new = LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to = support LISP
replication = engineering use-cases. = replication engineering use-cases.
=
o Changed = references to new LISP RFCs. o = Changed references to new LISP RFCs.
=
B.14. Changes to = draft-ietf-lisp-lcaf-01.txt B.15. Changes to = draft-ietf-lisp-lcaf-01.txt
=
o Submitted = January 2013. o Submitted January = 2013.
=
o Change = longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in = section 4.4.
=
o Added = reference to WGS-84 in section 4.4. = o Added reference to WGS-84 in section 4.4.
=
B.15. Changes to = draft-ietf-lisp-lcaf-00.txt B.16. Changes to = draft-ietf-lisp-lcaf-00.txt
=
o Posted = first working group draft August 2012. = o Posted first working group draft August 2012.
=
o This draft = was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from = draft-farinacci-lisp-lcaf-10.txt.
=
Authors' = Addresses Authors' Addresses
=
Dino = Farinacci Dino Farinacci
= lispers.net lispers.net
San Jose, = CA San Jose, CA
 End of changes. 42 change blocks. 
108 lines changed or = deleted 143 lines changed or = added

This = html diff was produced by rfcdiff 1.45. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Disposition: attachment; filename=draft-ietf-lisp-lcaf-15.txt Content-Type: text/plain; name="draft-ietf-lisp-lcaf-15.txt" Content-Transfer-Encoding: quoted-printable Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental D. Meyer Expires: March 23, 2017 Brocade J. Snijders NTT Communications September 19, 2016 LISP Canonical Address Format (LCAF) draft-ietf-lisp-lcaf-15 Abstract This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 23, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Farinacci, et al. Expires March 23, 2017 [Page 1] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.5. Multicast Group Membership Information . . . . . . . . . 14 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 16 4.7. Storing Security Data in the Mapping Database . . . . . . 17 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19 4.9. Replication List Entries for Multicast Forwarding . . . . 21 4.10. Applications for AFI List Type . . . . . . . . . . . . . 22 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26 5. Experimental LISP Canonical Address Applications . . . . . . 27 5.1. Convey Application Specific Data . . . . . . . . . . . . 27 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 28 5.3. PETR Admission Control Functionality . . . . . . . . . . 30 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 40 Farinacci, et al. Expires March 23, 2017 [Page 2] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 41 B.12. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction The LISP architecture and protocols [RFC6830] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in LISP control messages using a general syntax that includes Address Family Identifier (AFI), length, and value fields. Currently defined AFIs include IPv4 and IPv6 addresses, which are formatted according to code-points assigned in [AFI] as follows: IPv4 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Farinacci, et al. Expires March 23, 2017 [Page 3] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 IPv6 Encoded Address: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 2 | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document describes the currently-defined AFIs the LISP protocol uses along with their encodings and introduces the LISP Canonical Address Format (LCAF) that can be used to define the LISP-specific encodings for arbitrary AFI values. 2. Definition of Terms Address Family Identifier (AFI): a term used to describe an address encoding in a packet. Address families are defined for IPv4 and IPv6. See [AFI] and [RFC3232] for details. The reserved AFI value of 0 is used in this specification to indicate an unspecified encoded address where the length of the address is 0 bytes following the 16-bit AFI value of 0. Unspecified Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. The host obtains a destination EID the same way it obtains a destination address today, for example through a DNS lookup or SIP exchange. The source EID is obtained via existing mechanisms used to set a host's "local" IP address. An EID is allocated to a host from an EID-prefix block associated with the site where the host is located. An EID can be used by a host to refer to other hosts. Farinacci, et al. Expires March 23, 2017 [Page 4] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress tunnel router (ETR). It is the output of a EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. 3. LISP Canonical Address Format Encodings IANA has assigned AFI value 16387 (0x4003) to the LISP architecture and protocols. This specification defines the encoding format of the LISP Canonical Address (LCA). This section defines all types for which an initial allocation in the LISP-LCAF registry is requested. See IANA Considerations section for the complete list of such types. The Address Family AFI definitions from [AFI] only allocate code- points for the AFI value itself. The length of the address or entity that follows is not defined and is implied based on conventional experience. When the LISP protocol uses LCAF definitions from this document, the AFI-based address lengths are specified in this document. When new LCAF definitions are defined in other use-case documents, the AFI-based address lengths for any new AFI encoded addresses are specified in those documents. The first 6 bytes of an LISP Canonical Address are followed by a variable number of fields of variable length: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Rsvd2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1: this 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Flags: this 8-bit field is for future definition and use. For now, set to zero on transmission and ignored on receipt. Type: this 8-bit field is specific to the LISP Canonical Address formatted encodings, currently allocated values are: Type 0: Null Body Type Farinacci, et al. Expires March 23, 2017 [Page 5] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Type 1: AFI List Type Type 2: Instance ID Type Type 3: AS Number Type Type 4: Application Data Type Type 5: Geo Coordinates Type Type 6: Opaque Key Type Type 7: NAT-Traversal Type Type 8: Nonce Locator Type Type 9: Multicast Info Type Type 10: Explicit Locator Path Type Type 11: Security Key Type Type 12: Source/Dest Key Type Type 13: Replication List Entry Type Type 14: JSON Data Model Type Type 15: Key/Value Address Pair Type Type 16: Encapsulation Format Type Rsvd2: this LCAF Type dependent 8-bit field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. See specific LCAF Type for specific bits not reserved. Length: this 16-bit field is in units of bytes and covers all of the LISP Canonical Address payload, starting and including the byte after the Length field. When including the AFI, an LCAF encoded address will have a minimum length of 8 bytes when the Length field is 0. The 8 bytes include the AFI, Flags, Type, Reserved, and Length fields. When the AFI is not next to encoded address in a control message, then the encoded address will have a minimum length of 6 bytes when the Length field is 0. The 6 bytes include the Flags, Type, Reserved, and Length fields. [RFC6830] states RLOC records are sorted when encoded in control messages so the locator-set has consistent order across all xTRs for Farinacci, et al. Expires March 23, 2017 [Page 6] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 a given EID. The sort order is based on sort-key {afi, RLOC- address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- Type}. Therefore, when a locator-set has a mix of AFI records and LCAF records, they are ordered from smallest to largest AFI value. 4. LISP Canonical Address Applications 4.1. Segmentation using LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-prefixes, their address spaces must remain segregated due to possible address duplication. An Instance ID in the address encoding can aid in making the entire AFI based address unique. Another use for the Instance ID LISP Canonical Address Format is when creating multiple segmented VPNs inside of a LISP site where keeping EID-prefix based subnets is desirable. Farinacci, et al. Expires March 23, 2017 [Page 7] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Instance ID LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 2 | IID mask-len | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IID mask-len: if the AFI is set to 0, then this format is not encoding an extended EID-prefix but rather an instance-ID range where the 'IID mask-len' indicates the number of high-order bits used in the Instance ID field for the range. Length value n: length in bytes of the AFI address that follows the Instance ID field including the AFI field itself. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The reason for the length difference is so that the maximum number of instances supported per mapping system is 2^32 while conserving space in the LISP data header. This comes at the expense of limiting the maximum number of instances per xTR to 2^24. If an xTR is configured with multiple instance-IDs where the value in the high-order 8 bits are the same, then the low-order 24 bits MUST be unique. AFI =3D x: x can be any AFI value from [AFI]. This LISP Canonical Address Type can be used to encode either EID or RLOC addresses. Usage: When used as a lookup key, the EID is regarded as a extended- EID in the mapping system. This encoding is used in EID records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 8] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.2. Carrying AS Numbers in the Mapping Database When an AS number is stored in the LISP Mapping Database System for either policy or documentation reasons, it can be encoded in a LISP Canonical Address. AS Number LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 3 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the AS Number field including the AFI field itself. AS Number: the 32-bit AS number of the autonomous system that has been assigned either the EID or RLOC that follows. AFI =3D x: x can be any AFI value from [AFI]. The AS Number Canonical Address Type can be used to encode either EID or RLOC addresses. The former is used to describe the LISP-ALT AS number the EID-prefix for the site is being carried for. The latter is used to describe the AS that is carrying RLOC based prefixes in the underlying routing system. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 9] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.3. Assigning Geo Coordinates to Locator Addresses If an ETR desires to send a Map-Reply describing the Geo Coordinates for each locator in its locator-set, it can use the Geo Coordinate Type to convey physical location information. Coordinates are specified using the WGS-84 (World Geodetic System) reference coordinate system [WGS-84]. Geo Coordinate LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Longitude and Latitude fields including the AFI field itself. N: When set to 1 means North, otherwise South. Latitude Degrees: Valid values range from 0 to 90 degrees above or below the equator (northern or southern hemisphere, respectively). Latitude Minutes: Valid values range from 0 to 59. Latitude Seconds: Valid values range from 0 to 59. E: When set to 1 means East, otherwise West. Longitude Degrees: Value values are from 0 to 180 degrees right or left of the Prime Meridian. Longitude Minutes: Valid values range from 0 to 59. Longitude Seconds: Valid values range from 0 to 59. Farinacci, et al. Expires March 23, 2017 [Page 10] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Altitude: Height relative to sea level in meters. This is a signed integer meaning that the altitude could be below sea level. A value of 0x7fffffff indicates no Altitude value is encoded. AFI =3D x: x can be any AFI value from [AFI]. The Geo Coordinates Canonical Address Type can be used to encode either EID or RLOC addresses. When used for EID encodings, you can determine the physical location of an EID along with the topological location by observing the locator-set. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 11] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.4. NAT Traversal Scenarios When a LISP system is conveying global address and mapped port information when traversing through a NAT device, the NAT-Traversal LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details. NAT-Traversal Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 7 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS UDP Port Number | ETR UDP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | MS RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Private ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR RLOC Address k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI addresses that follows the UDP Port Number field including the AFI fields themselves. MS UDP Port Number: this is the UDP port number of the Map-Server and is set to 4342. ETR UDP Port Number: this is the port number returned to a LISP system which was copied from the source port from a packet that has flowed through a NAT device. AFI =3D x: x can be any AFI value from [AFI]. Global ETR RLOC Address: this is an address known to be globally unique built by NAT-traversal functionality in a LISP router. MS RLOC Address: this is the address of the Map-Server used in the destination RLOC of a packet that has flowed through a NAT device. Farinacci, et al. Expires March 23, 2017 [Page 12] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Private ETR RLOC Address: this is an address known to be a private address inserted in this LCAF format by a LISP router that resides on the private side of a NAT device. RTR RLOC Address: this is an encapsulation address used by an ITR or PITR which resides behind a NAT device. This address is known to have state in a NAT device so packets can flow from it to the LISP ETR behind the NAT. There can be one or more NAT Reencapsulating Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses supplied in these set of fields. The number of RTRs encoded is determined by the LCAF length field. When there are no RTRs supplied, the RTR fields can be omitted and reflected by the LCAF length field or an AFI of 0 can be used to indicate zero RTRs encoded. Usage: This encoding can be used in Info-Request and Info-Reply messages. The mapping system does not store this information. The information is used by an xTR and Map-Server to convey private and public address information when traversing NAT and firewall devices. Farinacci, et al. Expires March 23, 2017 [Page 13] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.5. Multicast Group Membership Information Multicast group information can be published in the mapping database. So a lookup on an group address EID can return a replication list of RLOC group addresses or RLOC unicast addresses. The intent of this type of unicast replication is to deliver packets to multiple ETRs at receiver LISP multicast sites. The locator-set encoding for this EID record type can be a list of ETRs when they each register with "Merge Semantics". The encoding can be a typical AFI encoded locator address. When an RTR list is being registered (with multiple levels according to [I-D.coras-lisp-re]), the Replication List Entry LCAF type is used for locator encoding. This LCAF encoding can be used to send broadcast packets to all members of a subnet when each EIDs are away from their home subnet location. Multicast Info Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 9 | Rsvd2 | 8 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source MaskLen| Group MaskLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source/Subnet Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Group Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Instance ID: the low-order 24-bits that can go into a LISP data header when the I-bit is set. See [RFC6830] for details. The use of the Instance-ID in this LCAF type is to associate a multicast forwarding entry for a given VPN. The instance-ID describes the VPN and is registered to the mapping database system as a 3-tuple of (Instance-ID, S-prefix, G-prefix). Source MaskLen: the mask length of the source prefix that follows. Farinacci, et al. Expires March 23, 2017 [Page 14] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Group MaskLen: the mask length of the group prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Source/Subnet Address is the source address or prefix for encoding a (S,G) multicast entry. Group Address is the group address or group prefix for encoding (S,G) or (*,G) multicast entries. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Farinacci, et al. Expires March 23, 2017 [Page 15] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.6. Traffic Engineering using Re-encapsulating Tunnels For a given EID lookup into the mapping database, this LCAF format can be returned to provide a list of locators in an explicit re- encapsulation path. See [I-D.farinacci-lisp-te] for details. Explicit Locator Path (ELP) Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 10 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 |L|P|S| AFI =3D x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reencap Hop k ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Lookup bit (L): this is the Lookup bit used to indicate to the user of the ELP to not use this address for encapsulation but to look it up in the mapping database system to obtain an encapsulating RLOC address. RLOC-Probe bit (P): this is the RLOC-probe bit which means the Reencap Hop allows RLOC-probe messages to be sent to it. When the R-bit is set to 0, RLOC-probes must not be sent. When a Reencap Hop is an anycast address then multiple physical Reencap Hops are using the same RLOC address. In this case, RLOC-probes are not needed because when the closest RLOC address is not reachable another RLOC address can be reachable. Strict bit (S): this is the strict bit which means the associated Rencap Hop is required to be used. If this bit is 0, the reencapsulator can skip this Reencap Hop and go to the next one in the list. Farinacci, et al. Expires March 23, 2017 [Page 16] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. This encoding does not need to be understood by the mapping system for mapping database lookups since this LCAF type is not a lookup key. 4.7. Storing Security Data in the Mapping Database When a locator in a locator-set has a security key associated with it, this LCAF format will be used to encode key material. See [I-D.ietf-lisp-ddt] for details. Farinacci, et al. Expires March 23, 2017 [Page 17] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Security Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 11 | Rsvd2 | 6 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Length | Key Material ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Key Material | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Locator Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that start with the Key Material field. Key Count: the Key Count field declares the number of Key sections included in this LCAF. Rsvd3: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. Key Algorithm: the Algorithm field identifies the key's cryptographic algorithm and specifies the format of the Public Key field. Rsvd4: this field is reserved for future use and MUST be transmitted as 0 and ignored on receipt. R bit: this is the revoke bit and, if set, it specifies that this Key is being Revoked. Key Length: this field determines the length in bytes of the Key Material field. Key Material: the Key Material field stores the key material. The format of the key material stored depends on the Key Algorithm field. AFI =3D x: x can be any AFI value from [AFI].This is the locator address that owns the encoded security key. Farinacci, et al. Expires March 23, 2017 [Page 18] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. 4.8. Source/Destination 2-Tuple Lookups When both a source and destination address of a flow needs consideration for different locator-sets, this 2-tuple key is used in EID fields in LISP control messages. When the Source/Dest key is registered to the mapping database, it can be encoded as a source- prefix and destination-prefix. When the Source/Dest is used as a key for a mapping database lookup the source and destination come from a data packet. Farinacci, et al. Expires March 23, 2017 [Page 19] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Source/Dest Key Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 12 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Source-ML | Dest-ML | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Source-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Destination-Prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Reserved: must be set to zero and ignore on receipt. Source-ML: the mask length of the source prefix that follows. Dest-ML: the mask length of the destination prefix that follows. AFI =3D x: x can be any AFI value from [AFI]. When a specific AFI = has its own encoding of a multicast address, this field must be either a group address or a broadcast address. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended EIDs are used in Map-Referral messages. Refer to [I-D.farinacci-lisp-te] for usage details of this LCAF type. Farinacci, et al. Expires March 23, 2017 [Page 20] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.9. Replication List Entries for Multicast Forwarding The Replication List Entry LCAF type is an encoding for a locator being used for unicast replication according to the specification in [I-D.coras-lisp-re]. This locator encoding is pointed to by a Multicast Info LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs) that are participating in an overlay distribution tree. Each RTR will register its locator address and its configured level in the distribution tree. Replication List Entry Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 13 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd3 | Rsvd4 | Level Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | RTR/ETR #n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Level Value: this value is associated with the level within the overlay distribution tree hierarchy where the RTR resides. The level numbers are ordered from lowest value being close to the ITR (meaning that ITRs replicate to level-0 RTRs) and higher levels are further downstream on the distribution tree closer to ETRs of multicast receiver sites. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. For efficiency reasons, all RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 23, 2017 [Page 21] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10. Applications for AFI List Type 4.10.1. Binding IPv4 and IPv6 Addresses When header translation between IPv4 and IPv6 is desirable a LISP Canonical Address can use the AFI List Type to carry a variable number of AFIs in one LCAF AFI. Address Binding LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 4 + 2 + 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | AFI =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI encoded addresses are used. This type of address format can be included in a Map-Request when the address is being used as an EID, but the Mapping Database System lookup destination can use only the IPv4 address. This is so a Mapping Database Service Transport System, such as LISP-ALT [RFC6836], can use the Map-Request destination address to route the control message to the desired LISP site. Usage: This encoding can be used in EID or RLOC records in Map- Requests, Map-Replies, Map-Registers, and Map-Notify messages. See subsections in this section for specific use cases. Farinacci, et al. Expires March 23, 2017 [Page 22] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.2. Layer-2 VPNs When MAC addresses are stored in the LISP Mapping Database System, the AFI List Type can be used to carry AFI 6. MAC Address LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. This address format can be used to connect layer-2 domains together using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. In this use-case, a MAC address is being used as an EID, and the locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or even another MAC address being used as an RLOC. See [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when doing EID mobility. Farinacci, et al. Expires March 23, 2017 [Page 23] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.3. ASCII Names in the Mapping Database If DNS names or URIs are stored in the LISP Mapping Database System, the AFI List Type can be used to carry an ASCII string where it is delimited by length 'n' of the LCAF Length encoding. ASCII LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 17 | DNS Name or URI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes AFI=3D17 field and the = null-terminated ASCII string (the last byte of 0 is included). Farinacci, et al. Expires March 23, 2017 [Page 24] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.4. Using Recursive LISP Canonical Address Encodings When any combination of above is desirable, the AFI List Type value can be used to carry within the LCAF AFI another LCAF AFI (for example, Application Specific Data see Section 5.1. Recursive LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 QQS or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 1 | IPv4 Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 18 when an AFI=3D1 IPv4 address = is included. This format could be used by a Mapping Database Transport System, such as LISP-ALT [RFC6836], where the AFI=3D1 IPv4 address is used as an EID and placed in the Map-Request destination address by the sending LISP system. The ALT system can deliver the Map-Request to the LISP destination site independent of the Application Data Type AFI payload values. When this AFI is processed by the destination LISP site, it can return different locator-sets based on the type of application or level of service that is being requested. Farinacci, et al. Expires March 23, 2017 [Page 25] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 4.10.5. Compatibility Mode Use Case A LISP system should use the AFI List Type format when sending to LISP systems that do not support a particular LCAF Type used to encode locators. This allows the receiving system to be able to parse a locator address for encapsulation purposes. The list of AFIs in an AFI List LCAF Type has no semantic ordering and a receiver should parse each AFI element no matter what the ordering. Compatibility Mode Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 1 | Rsvd2 | 8 + 14 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 5 | Rsvd2 | 12 + 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Latitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Longitude Degrees | Minutes | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Altitude | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 0 | AFI =3D 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a system does not recognized the Geo Coordinate LCAF Type that is accompanying a locator address, an encoder can include the Geo Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in the list is encoded with a valid AFI value to identify the locator address. A LISP system is required to support the AFI List LCAF Type to use this procedure. It would skip over 10 bytes of the Geo Coordinate LCAF Type to get to the locator address encoding (an IPv4 locator address). A LISP system that does support the Geo Coordinate LCAF Type can support parsing the locator address within the Geo Coordinate LCAF encoding or in the locator encoding that follows in the AFI List LCAF. Farinacci, et al. Expires March 23, 2017 [Page 26] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5. Experimental LISP Canonical Address Applications 5.1. Convey Application Specific Data When a locator-set needs to be conveyed based on the type of application or the Per-Hop Behavior (PHB) of a packet, the Application Data Type can be used. Application Data LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 4 | Rsvd2 | 12 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP TOS, IPv6 TC, or Flow Label | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Port (lower-range) | Local Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Port (lower-range) | Remote Port (upper-range) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the 8-byte Application Data fields including the AFI field itself. IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow Label used in an IPv6 header. Local Port/Remote Port Ranges: these fields are from the TCP, UDP, or SCTP transport header. A range can be specified by using a lower value and an upper value. When a single port is encoded, the lower and upper value fields are the same. AFI =3D x: x can be any AFI value from [AFI]. The Application Data Canonical Address Type is used for an EID encoding when an ITR wants a locator-set for a specific application. When used for an RLOC encoding, the ETR is supplying a locator-set for each specific application is has been configured to advertise. Usage: This encoding can be used in EID records in Map-Requests, Map- Replies, Map-Registers, and Map-Notify messages. When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended Farinacci, et al. Expires March 23, 2017 [Page 27] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 EIDs are used in Map-Referral messages. This LCAF type is used as a lookup key to the mapping system that can return a longest-match or exact-match entry. 5.2. Generic Database Mapping Lookups When the LISP Mapping Database system holds information accessed by a generic formatted key (where the key is not the usual IPv4 or IPv6 address), an opaque key may be desirable. Opaque Key LISP Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 6 | Rsvd2 | 3 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Field Num | Key Wildcard Fields | Key . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the type's payload. The value n is the number of bytes that follow this Length field. Farinacci, et al. Expires March 23, 2017 [Page 28] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Key Field Num: the value of this field is the the number of "Key" sub-fields minus 1, the "Key" field can be broken up into. So if this field has a value of 0, there is 1 sub-field in the "Key". The width of the sub-fields are fixed length. So for a key size of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes each in length. Allowing for a reasonable number of 16 sub- field separators, valid values range from 0 to 15. Key Wildcard Fields: describes which fields in the key are not used as part of the key lookup. This wildcard encoding is a bitfield. Each bit is a don't-care bit for a corresponding field in the key. Bit 0 (the low-order bit) in this bitfield corresponds the first field, the low-order field in the key, bit 1 the second field, and so on. When a bit is set in the bitfield it is a don't-care bit and should not be considered as part of the database lookup. When the entire 16-bits is set to 0, then all bits of the key are used for the database lookup. Key: the variable length key used to do a LISP Database Mapping lookup. The length of the key is the value n (as shown above). Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 23, 2017 [Page 29] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.3. PETR Admission Control Functionality When a public PETR device wants to verify who is encapsulating to it, it can check for a specific nonce value in the LISP encapsulated packet. To convey the nonce to admitted ITRs or PITRs, this LCAF format is used in a Map-Register or Map-Reply locator-record. Nonce Locator Canonical Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 8 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the AFI address that follows the Nonce field including the AFI field itself. Reserved: must be set to zero and ignore on receipt. Nonce: this is a nonce value returned by an ETR in a Map-Reply locator-record to be used by an ITR or PITR when encapsulating to the locator address encoded in the AFI field of this LCAF type. This nonce value is inserted in the nonce field in the LISP header encapsulation. AFI =3D x: x can be any AFI value from [AFI]. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 23, 2017 [Page 30] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.4. Data Model Encoding This type allows a JSON data model to be encoded either as an EID or RLOC. JSON Data Model Type Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 14 | Rsvd2 |B| 2 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JSON length | JSON binary/text encoding ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Optional Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of the fields that follow the "JSON length" field. Rsvd{1,2}: must be set to zero and ignore on receipt. B bit: indicates that the JSON field is binary encoded according to [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is based on text encoding according to [RFC7159]. JSON length: length in octets of the following 'JSON binary/text encoding' field. JSON binary/text encoding field: a variable length field that contains either binary or text encodings. AFI =3D x: x can be any AFI value from [AFI]. A specific AFI has = its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Usage: This is an experimental type where the usage has not been defined yet. Farinacci, et al. Expires March 23, 2017 [Page 31] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 5.5. Encoding Key/Value Address Pairs The Key/Value pair is for example useful for attaching attributes to other elements of LISP packets, such as EIDs or RLOCs. When attaching attributes to EIDs or RLOCs, it's necessary to distinguish between the element that should be used as EID or RLOC, and hence as key for lookups, and additional attributes. This is especially the case when the difference cannot be determined from the types of the elements, such as when two IP addresses are being used. Key/Value Pair Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 15 | Rsvd2 | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address as Key ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D y | Address as Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length value n: length in bytes of fields that follow. Rsvd{1,2}: must be set to zero and ignore on receipt. AFI =3D x: x is the "Address as Key" AFI that can have any value = from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map- Reply message. Address as Key: this AFI encoded address will be attached with the attributes encoded in "Address as Value" which follows this field. AFI =3D y: y is the "Address of Value" AFI that can have any value from [AFI]. A specific AFI has its own encoding of either a unicast or multicast locator address. All RTR/ETR entries for the same level should be combined together by a Map-Server to avoid searching through the entire multi-level list of locator entries in a Map-Reply message. Address as Value: this AFI encoded address will be the attribute address that goes along with "Address as Key" which precedes this field. Farinacci, et al. Expires March 23, 2017 [Page 32] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Usage: This is an experimental type where the usage has not been defined yet. 5.6. Multiple Data-Planes Overlays are becoming popular in many parts of the network which have created an explosion of data-plane encapsulation headers. Since the LISP mapping system can hold many types of address formats, it can represent the encapsulation format supported by an RLOC as well. When an encapsulator receives a Map-Reply with an Encapsulation Format LCAF Type encoded in an RLOC-record, it can select an encapsulation format, that it can support, from any of the encapsulation protocols which have the bit set to 1 in this LCAF type. Farinacci, et al. Expires March 23, 2017 [Page 33] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Encapsulation Format Address Format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D 16387 | Rsvd1 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D 16 | Rsvd2 | 4 + n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI =3D x | Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsvd1/Rsvd2: must be set to zero and ignored on receipt. Length value n: length in bytes of the AFI address that follows the next 32-bits including the AFI field itself. Reserved-for-Future-Encapsulations: must be set to zero and ignored on receipt. This field will get bits allocated to future encapsulations, as they are created. L: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer3 LISP encapsulation using destination UDP port 4341 [RFC6830]. l: The RLOCs listed in the AFI encoded addresses in the next longword can accept layer2 LISP encapsulation using destination UDP port 8472 [I-D.smith-lisp-layer2]. V: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN encapsulation using destination UDP port 4789 [RFC7348]. v: The RLOCs listed in the AFI encoded addresses in the next longword can accept VXLAN-GPE encapsulation using destination UDP port 4790 [I-D.quinn-vxlan-gpe]. N: The RLOCs listed in the AFI encoded addresses in the next longword can accept NV-GRE encapsulation using IPv4/ IPv6 protocol number 47 [RFC7637]. G: The RLOCs listed in the AFI encoded addresses in the next longword can accept GENEVE encapsulation using destination UDP port 6081 [I-D.gross-geneve]. Farinacci, et al. Expires March 23, 2017 [Page 34] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 U: The RLOCs listed in the AFI encoded addresses in the next longword can accept GUE encapsulation using destination UDP port TBD [I-D.herbert-gue]. Usage: This encoding can be used in RLOC records in Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Farinacci, et al. Expires March 23, 2017 [Page 35] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 6. Security Considerations There are no security considerations for this specification. The security considerations are documented for the protocols that use LISP Canonical Addressing. The use of the Geo-Coordinates LCAF Type may raise physical privacy issues. Care should be taken when configuring the mapping system to use specific policy parameters so geo-location information is not returned gratutiosly. 7. IANA Considerations This document defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. Such address format is based on a fixed AFI (16387) and a LISP LCAF Type field. The LISP LCAF Type field is an 8-bit field specific to the LISP Canonical Address formatted encodings, for which IANA is to create and maintain a new registry (as outlined in [RFC5226]) entitled "LISP LCAF Type". Initial values for the LISP LCAF Type registry are given below. Future assignments are to be made through expert review with a specification required publication. Assignments consist of a LISP LCAF Type name and its associated value: +-------+------------------------------+------------+ | Value | LISP LCAF Type Name | Definition | +-------+------------------------------+------------+ | 0 | Null Body Type | Section 3 | | 1 | AFI List Type | Section 3 | | 2 | Instance ID Type | Section 3 | | 3 | AS Number Type | Section 3 | | 5 | Geo Coordinates Type | Section 3 | | 7 | NAT-Traversal Type | Section 3 | | 9 | Multicast Info Type | Section 3 | | 10 | Explicit Locator Path Type | Section 3 | | 11 | Security Key Type | Section 3 | | 12 | Source/Dest Key Type | Section 3 | | 13 | Replication List Entry Type | Section 3 | +-------+------------------------------+------------+ Table 1: LISP LCAF Type Initial Values Farinacci, et al. Expires March 23, 2017 [Page 36] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, . Farinacci, et al. Expires March 23, 2017 [Page 37] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 8.2. Informative References [AFI] IANA, , "Address Family Identifier (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, Febuary 2007. [I-D.coras-lisp-re] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-08 (work in progress), November 2015. [I-D.ermagan-lisp-nat-traversal] Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, F., and C. White, "NAT traversal for LISP", draft-ermagan- lisp-nat-traversal-11 (work in progress), August 2016. [I-D.farinacci-lisp-te] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", draft-farinacci-lisp-te-11 (work in progress), September 2016. [I-D.gross-geneve] Gross, J., Sridhar, T., Garg, P., Wright, C., Ganga, I., Agarwal, P., Duda, K., Dutt, D., and J. Hudson, "Geneve: Generic Network Virtualization Encapsulation", draft- gross-geneve-02 (work in progress), October 2014. [I-D.herbert-gue] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", draft-herbert-gue-03 (work in progress), March 2015. [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- ddt-08 (work in progress), September 2016. [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- mobility-00 (work in progress), April 2016. Farinacci, et al. Expires March 23, 2017 [Page 38] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 [I-D.quinn-vxlan-gpe] Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P., and D. Melman, "Generic Protocol Extension for VXLAN", draft-quinn-vxlan-gpe-04 (work in progress), February 2015. [I-D.smith-lisp-layer2] Smith, M., Dutt, D., Farinacci, D., and F. Maino, "Layer 2 (L2) LISP Encapsulation Format", draft-smith-lisp- layer2-03 (work in progress), September 2013. [JSON-BINARY] "Universal Binary JSON Specification", URL http://ubjson.org. [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic System 1984", NIMA TR8350.2, January 2000, . Appendix A. Acknowledgments The authors would like to thank Vince Fuller, Gregg Schudel, Jesper Skriver, Luigi Iannone, Isidor Kouvelas, and Sander Steffann for their technical and editorial commentary. The authors would like to thank Victor Moreno for discussions that lead to the definition of the Multicast Info LCAF type. The authors would like to thank Parantap Lahiri and Michael Kowal for discussions that lead to the definition of the Explicit Locator Path (ELP) LCAF type. The authors would like to thank Fabio Maino and Vina Ermagan for discussions that lead to the definition of the Security Key LCAF type. The authors would like to thank Albert Cabellos-Aparicio and Florin Coras for discussions that lead to the definition of the Replication List Entry LCAF type. Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for suggesting new LCAF types. Thanks also goes to Terry Manderson for assistance obtaining a LISP AFI value from IANA. Farinacci, et al. Expires March 23, 2017 [Page 39] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-lcaf-15.txt o Submitted September 2016. o Addressed comments from Routing Directorate reviewer Stig Venass. B.2. Changes to draft-ietf-lisp-lcaf-14.txt o Submitted July 2016. o Fix IDnits errors and comments from Luigi Iannone, document shepherd. B.3. Changes to draft-ietf-lisp-lcaf-13.txt o Submitted May 2016. o Explain the Instance-ID LCAF Type is 32-bits in length and the Instance-ID field in the LISP encapsulation header is 24-bits. B.4. Changes to draft-ietf-lisp-lcaf-12.txt o Submitted March 2016. o Updated references and document timer. o Removed the R, J, and L bits from the Multicast Info Type LCAF since working group decided to not go forward with draft- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- signal-free-00.txt. B.5. Changes to draft-ietf-lisp-lcaf-11.txt o Submitted September 2015. o Reflecting comments from Prague LISP working group. o Readying document for a LISP LCAF registry, RFC publication, and for new use-cases that will be defined in the new charter. Farinacci, et al. Expires March 23, 2017 [Page 40] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.6. Changes to draft-ietf-lisp-lcaf-10.txt o Submitted June 2015. o Fix coauthor Job's contact information. B.7. Changes to draft-ietf-lisp-lcaf-09.txt o Submitted June 2015. o Fix IANA Considerations section to request a registry to allocate and track LCAF Type values. B.8. Changes to draft-ietf-lisp-lcaf-08.txt o Submitted April 2015. o Comment from Florin. The Application Data Type length field has a typo. The field should be labeled "12 + n" and not "8 + n". o Fix length fields in the sections titled "Using Recursive LISP Canonical Address Encodings", "Generic Database Mapping Lookups", and "Data Model Encoding". B.9. Changes to draft-ietf-lisp-lcaf-07.txt o Submitted December 2014. o Add a new LCAF Type called "Encapsulation Format" so decapsulating xTRs can inform encapsulating xTRs what data-plane encapsulations they support. B.10. Changes to draft-ietf-lisp-lcaf-06.txt o Submitted October 2014. o Make it clear how sorted RLOC records are done when LCAFs are used as the RLOC record. B.11. Changes to draft-ietf-lisp-lcaf-05.txt o Submitted May 2014. o Add a length field of the JSON payload that can be used for either binary or text encoding of JSON data. Farinacci, et al. Expires March 23, 2017 [Page 41] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 B.12. Changes to draft-ietf-lisp-lcaf-04.txt o Submitted January 2014. o Agreement among ELP implementors to have the AFI 16-bit field adjacent to the address. This will make the encoding consistent with all other LCAF type address encodings. B.13. Changes to draft-ietf-lisp-lcaf-03.txt o Submitted September 2013. o Updated references and author's affilations. o Added Instance-ID to the Multicast Info Type so there is relative ease in parsing (S,G) entries within a VPN. o Add port range encodings to the Application Data LCAF Type. o Add a new JSON LCAF Type. o Add Address Key/Value LCAF Type to allow attributes to be attached to an address. B.14. Changes to draft-ietf-lisp-lcaf-02.txt o Submitted March 2013. o Added new LCAF Type "Replication List Entry" to support LISP replication engineering use-cases. o Changed references to new LISP RFCs. B.15. Changes to draft-ietf-lisp-lcaf-01.txt o Submitted January 2013. o Change longitude range from 0-90 to 0-180 in section 4.4. o Added reference to WGS-84 in section 4.4. B.16. Changes to draft-ietf-lisp-lcaf-00.txt o Posted first working group draft August 2012. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. Farinacci, et al. Expires March 23, 2017 [Page 42] =0C Internet-Draft LISP Canonical Address Format (LCAF) September 2016 Authors' Addresses Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com Dave Meyer Brocade San Jose, CA USA Email: dmm@1-4-5.net Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ NL Email: job@ntt.net Farinacci, et al. Expires March 23, 2017 [Page 43] --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_3612B9A9-65E7-45CD-BFD8-EE24EBFDD2E4-- From nobody Mon Sep 19 16:07:53 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A60012B007 for ; Mon, 19 Sep 2016 16:07:51 -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=venaas-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XBnUlmouBhK for ; Mon, 19 Sep 2016 16:07:47 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 9AD7A12B00C for ; Mon, 19 Sep 2016 16:07:46 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id y6so77052lff.1 for ; Mon, 19 Sep 2016 16:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KWEoakPNxyt7E70Tq26NlIO4ra/i9W/rrgRx03b3SFI=; b=E9SSJkRzGYZUD7LABoLABQ5pYgHfnUR6bBjAg60Htsw76XuvF/GDMViO7oYSLh7f76 CNo+VAEYKSHkcpNgw4bNXydEuHXHB6qZ1xmW3PJ8CVAAwV4mukdEVsND6AGsFfG7jNLj QTeY60rFu+nAPvWywhTGaSGrOpLCFGRVdolKttTr98RDLkY+vvnH3L/OKQ9W/YlwNpFG Jfpsw68qHHTiO5FDc0AphgXHAtfudmVzBvAwcwGBZJfTiaQ4lstrGsCsD5jX4lqKkKlx xb56r3aZYmGDrXmvq0u1MxcwGPo5rw++WafUQqMCyT6ssFxjktaKbaG6DUmC0gyzjhiu ErXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KWEoakPNxyt7E70Tq26NlIO4ra/i9W/rrgRx03b3SFI=; b=AXL6f87XxARlBZqe2VCbA77pvCyQ307ig7spD4m/oeoEFz6cP+5T2I7mJcSv/9rde+ pErziYYl0yMEVcB/RY7xDIU/EDQyPJy0gM7KnhdHZYlsCBfW3y63rA2AiOc1l+kyIipS KAeLy9ZsEXMEcsbG6Q1ojxIdN29pwIPggVVufbvZDRL6EjN7egdH+TP7Bo7PvoTPmdEe JOhVIzqLX7AiKtCdPPYuFYoLxTEpj6i90Y+23i+yUaz6aI6l9n+nMqPCasYeiXnEIT7P /PMXOsN7aMdplmU5ANZaCuE0AbriVjgmUe0w02q+3zC0wt+2Y2Rs++jP+YgA8IY6wlwx p4OA== X-Gm-Message-State: AE9vXwNR5bE2PlXvSwcqP819GE3pKQ1rLFACeYJU70duPYgULof4QstZhfB/sQ+EGEgl2dxjrY6JwuL0OG7blA== X-Received: by 10.46.1.132 with SMTP id f4mr11609488lji.57.1474326464740; Mon, 19 Sep 2016 16:07:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.28.15 with HTTP; Mon, 19 Sep 2016 16:07:44 -0700 (PDT) In-Reply-To: <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> From: Stig Venaas Date: Mon, 19 Sep 2016 16:07:44 -0700 Message-ID: To: Dino Farinacci Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 23:07:51 -0000 Hi The changes look good. Stig On Mon, Sep 19, 2016 at 8:54 AM, Dino Farinacci wrote= : >> On Sep 9, 2016, at 4:15 PM, Stig Venaas wrote: >> >>>> In section 3 we have this paragraph: >>>> >>>> The Address Family AFI definitions from [AFI] only allocate code- >>>> points for the AFI value itself. The length of the address or entity >>>> that follows is not defined and is implied based on conventional >>>> experience. Where the LISP protocol uses LISP Canonical Addresses >>>> specifically, the address length definitions will be in this >>>> specification and take precedent over any other specification. >>>> >>>> I'm not sure what conventional experience means. Please try to find a >>> >>> Well like I said above, the AFI values defined in the AFI document are = just type values and there is no length defined. So =E2=80=9Cconventional w= isdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we know wh= at follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >> >> In theory there should be standards/documents specifying this for each >> of the address types, and maybe could write that people should see the >> respective standards or something. I don't know if this exists for all >> the types though. > > It does not. But how about I promise you that when there is a new use-cas= e for a specific AFI, we=E2=80=99ll make sure that the AFI and its length a= re defined in that use-case document. > > Like I said, we have this for AFI=3D17 already. So I have already set an = example. > >>> better way to say it. Regarding the last sentence, what if a you want >>>> to define new LCAF encodings in the future? Is it good to say that thi= s >>>> specification takes precedent over any other? >>> >>> LCAF encodings and definitions do not change the length of an AFI encod= ed address. So I am not sure what you mean. >> >> The last sentence says "Where the LISP protocol uses LISP Canonical >> Addresses specifically, the address length definitions will be in this >> specification and take precedent over any other specification.". What >> if you in the future would like to write a separate specification that >> defines additional LISP Canonical address formats? > > Okay, I have clarified that new LCAFs that are defined in other documents= will specify length and formatting definitions. > >>> In section 3 we have this paragraph: >>>> >>>> Length: this 16-bit field is in units of bytes and covers all of the >>>> LISP Canonical Address payload, starting and including the byte >>>> after the Length field. So any LCAF encoded address will have a >>>> minimum length of 8 bytes when the Length field is 0. The 8 bytes >>>> include the AFI, Flags, Type, Reserved, and Length fields. When >>>> the AFI is not next to encoded address in a control message, then >>>> the encoded address will have a minimum length of 6 bytes when the >>>> Length field is 0. The 6 bytes include the Flags, Type, Reserved, >>>> and Length fields. >>>> >>>> Can you phrase this differently? First it says that any LCAF encoded >>> >>> No not really. It is precise up to the sentence =E2=80=9CWhen the AFI i= s not ..=E2=80=9D. >>> >>>> address has a minimum length of 8, but then it goes on to say how it >>>> sometimes is only 6. I understand what you're trying to say, but there >>>> may be a better way of stating it. >>> >>> This special case is for some LISP control-messages where the AFI is an= other place in the message but the address is somewhere else. Rather than h= ave the AFI appear twice, the LCAF length needs to be different. >>> >>> The length field always includes the entire contiguous set of LCAF byte= s including type, flags, length field, etc. >>> >>> The language is precise and accurate. Let me know how you think stating= what I did in this comment response can be put in without writing a lot of= text about a special case. >> >> The problem I see is that first you write "So any LCAF encoded address >> will have a minimum length of 8 bytes when the Length field is 0." and >> then you write "then the encoded address will have a minimum length of >> 6 bytes when the Length field is 0." I understand what you mean, but I >> feel this is a bit confusing. >> >> Maybe you could say something like: >> >> When including the AFI, an LCAF encoded address will have a minimum >> length of 8 bytes when the Length field is 0. Or start by saying that >> the minimal length is 6, and then say that it will then be 8 when the >> AFI is included. > > Changed to add your suggestion. Thanks. > >>>> Section 4.10 >>>> In this section there are several examples of using the AFI List Type, >>>> but I miss a general definition. It appears that there can be a variab= le >>>> number of AFIs in the list. Any number > 0? It might be useful to have >>> >>> Yes, a variable number. >> >> How about adding a few lines of text to 4.10 saying that you can have >> a variable number etc., explaining briefly what the general format is. >> And then say that what follows are examples? > > Done. > >> Section 4.10.3 >>>> Isn't it unusual to include the 0 termination? Since you know the >>>> length it is not really needed. When parsing one will need to check >>>> the length either way, what should one do it the string accidentally >>>> is not 0-terminated? >>> >>> Well the AFI definition in [AFI] doesn=E2=80=99t say how to terminate t= he string. But the length field will imply it. However, I wrote the =E2=80= =9Cdistinguished-name=E2=80=9D draft to specify when AFI=3D17 is used (not = only in a LCAF but by itself), how to terminate the string. I could include= that reference, but that draft is not a working group document. >>> >>> So please advise. >> >> Currently it says: >> >> Length value n: length in bytes AFI=3D17 field and the null-terminate= d >> ASCII string (the last byte of 0 is included). >> >> It might make sense to 0 terminate the DN in some cases, but at least >> here we know the string length from the value of n, so I think it >> would be better to drop it here. And as I mentioned, you cannot rely >> on the 0 for parsing, to be on the safe side you would use n anyway. > > You want to terminate the string in all cases. Because there are cases wh= ere AFI=3D17 is not used inside an LCAF encoding. And where there is no len= gth to convey the string length. And the Distinguished-Name use-case Intern= et Draft specs this for both LCAF and non-LCAF applications. > >>>> Section 7 >>>> It looks like the table in the IANA considerations doesn't include all >>>> the types defined in this document. >>> >>> That was done intentionally. The ones that are experimental are not in = this section 7 list because there is no use-case document for it yet. Maybe= the chairs can explain this better than me. >> >> I think it's still useful. If someone sees the type used, they can >> look it up in the registry. It also helps avoid that someone perhaps >> tries to reuse one of these types in new documents. If you really want >> to use one of the code points for something else in the future, a new >> document could always update the registry. > > Did Luigi=E2=80=99s response satisfy your comment? > >> BTW, it also makes me wonder if it is worth reserving any LCAF types >> for experiments. > > The space is large enough for FCFS. > >> Regards, >> Stig > > See new version enclosed. Let me know when I can post it if you like the = changes. > > Thanks again, > Dino > > > > > > > > From nobody Mon Sep 19 17:06:48 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697EE12B04C; Mon, 19 Sep 2016 17:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 6qstOtBH0rLL; Mon, 19 Sep 2016 17:06:45 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 5847E12B03B; Mon, 19 Sep 2016 17:06:45 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id 21so508195pfy.0; Mon, 19 Sep 2016 17:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ej/NgXIKuNaGm6FTvH5CnHjlXs/HkuPCDh29wUxJjx8=; b=GxkEvjeDop4m3/dqalC56DaAsUm+YCqrzdMnroKnjXkPCwOJ4ri/nS7gRUl7/JzMD2 Rf++GH5LTvd72A4fyI/5X/0StRxC/HOf17VwRwmUujBUVGQpi5q4nRCAlsCxU2LSG+v0 d96y1CSM4ivtxVxQVMOJylYIrNeb/FPJAG8a/+Gq8C8nC56CQ4s9zHUxPheJXPAqsFFb BYNSks7cHmypAUJyVJ+fbfIo4gpti5qQqj6niHBMVGCIgp7FZo5AANCCgDP/YqdRvb2J D3Dspfm7ZohVL7UqaHkN/WMGkcvKxqXv3+46hVCQWr/hJpwUgSnaCJSHXErTtm5ideK4 rHcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ej/NgXIKuNaGm6FTvH5CnHjlXs/HkuPCDh29wUxJjx8=; b=lHBsKuBpB6cIZeezV/qJxZCtUjdQBVV7D9/XFaCnY5Jk7uYOXWl5rwMGjpn5m6BNtl hCktfDKaVaKATUmC3EeDSdjCaJnfOPIswTFxENYTorp4JyXQyyh7B9t5KFlLCcyRO/u2 vQZhF3S5j22QncZwKsKddaaf30m672ZlcEkAJrYDFenfXUw0SwmJ2OfHv+3joFMzdAMk 6yyAzzgeVEG9lDMnAnyN+8hgSiLRMJZzRX5LIZzRVIoIqaOPxzsawqJNvIRHIXUETzns sYivdsFjnx1eV5juUzjzV/7tsa/WbIk1AtghrQNmejoZcy/ttKBJt0UGnkdHP9xcg3rD tt/w== X-Gm-Message-State: AE9vXwNKYify1feM9rNkjuemc5Km0ti/QGIHpTWrM9ofAqXvYK0U5Wpyag+iOi5Sw+bcuA== X-Received: by 10.98.99.67 with SMTP id x64mr50941910pfb.26.1474330004941; Mon, 19 Sep 2016 17:06:44 -0700 (PDT) Received: from ?IPv6:2601:646:8d01:89f0:a105:345:d1c0:66ba? ([2601:646:8d01:89f0:a105:345:d1c0:66ba]) by smtp.gmail.com with ESMTPSA id 21sm25747662pfo.80.2016.09.19.17.06.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Sep 2016 17:06:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dino Farinacci In-Reply-To: Date: Mon, 19 Sep 2016 17:06:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2A6FBD83-97A1-45F9-8875-81CF6FE5B7E8@gmail.com> References: <551BDE7B-6BA3-4336-B92A-395FBE4A571D@gmail.com> <606F6D6C-B9A9-402E-8C04-96EF867C6E89@gmail.com> To: Stig Venaas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, LISP mailing list list , draft-ietf-lisp-lcaf.all@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-lisp-lcaf-14.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 00:06:47 -0000 -15 posted. Thanks a lot Stig! Dino > On Sep 19, 2016, at 4:07 PM, Stig Venaas wrote: >=20 > Hi >=20 > The changes look good. >=20 > Stig >=20 >=20 > On Mon, Sep 19, 2016 at 8:54 AM, Dino Farinacci = wrote: >>> On Sep 9, 2016, at 4:15 PM, Stig Venaas wrote: >>>=20 >>>>> In section 3 we have this paragraph: >>>>>=20 >>>>> The Address Family AFI definitions from [AFI] only allocate code- >>>>> points for the AFI value itself. The length of the address or = entity >>>>> that follows is not defined and is implied based on conventional >>>>> experience. Where the LISP protocol uses LISP Canonical Addresses >>>>> specifically, the address length definitions will be in this >>>>> specification and take precedent over any other specification. >>>>>=20 >>>>> I'm not sure what conventional experience means. Please try to = find a >>>>=20 >>>> Well like I said above, the AFI values defined in the AFI document = are just type values and there is no length defined. So =E2=80=9Cconventio= nal wisdom=E2=80=9D means that if a spec says an AFI value 1 is IPv4, we = know what follows is 4 bytes. Ditto for IPv6, MAC addresses, etc. >>>=20 >>> In theory there should be standards/documents specifying this for = each >>> of the address types, and maybe could write that people should see = the >>> respective standards or something. I don't know if this exists for = all >>> the types though. >>=20 >> It does not. But how about I promise you that when there is a new = use-case for a specific AFI, we=E2=80=99ll make sure that the AFI and = its length are defined in that use-case document. >>=20 >> Like I said, we have this for AFI=3D17 already. So I have already set = an example. >>=20 >>>> better way to say it. Regarding the last sentence, what if a you = want >>>>> to define new LCAF encodings in the future? Is it good to say that = this >>>>> specification takes precedent over any other? >>>>=20 >>>> LCAF encodings and definitions do not change the length of an AFI = encoded address. So I am not sure what you mean. >>>=20 >>> The last sentence says "Where the LISP protocol uses LISP Canonical >>> Addresses specifically, the address length definitions will be in = this >>> specification and take precedent over any other specification.". = What >>> if you in the future would like to write a separate specification = that >>> defines additional LISP Canonical address formats? >>=20 >> Okay, I have clarified that new LCAFs that are defined in other = documents will specify length and formatting definitions. >>=20 >>>> In section 3 we have this paragraph: >>>>>=20 >>>>> Length: this 16-bit field is in units of bytes and covers all of = the >>>>> LISP Canonical Address payload, starting and including the byte >>>>> after the Length field. So any LCAF encoded address will have = a >>>>> minimum length of 8 bytes when the Length field is 0. The 8 = bytes >>>>> include the AFI, Flags, Type, Reserved, and Length fields. = When >>>>> the AFI is not next to encoded address in a control message, = then >>>>> the encoded address will have a minimum length of 6 bytes when = the >>>>> Length field is 0. The 6 bytes include the Flags, Type, = Reserved, >>>>> and Length fields. >>>>>=20 >>>>> Can you phrase this differently? First it says that any LCAF = encoded >>>>=20 >>>> No not really. It is precise up to the sentence =E2=80=9CWhen the = AFI is not ..=E2=80=9D. >>>>=20 >>>>> address has a minimum length of 8, but then it goes on to say how = it >>>>> sometimes is only 6. I understand what you're trying to say, but = there >>>>> may be a better way of stating it. >>>>=20 >>>> This special case is for some LISP control-messages where the AFI = is another place in the message but the address is somewhere else. = Rather than have the AFI appear twice, the LCAF length needs to be = different. >>>>=20 >>>> The length field always includes the entire contiguous set of LCAF = bytes including type, flags, length field, etc. >>>>=20 >>>> The language is precise and accurate. Let me know how you think = stating what I did in this comment response can be put in without = writing a lot of text about a special case. >>>=20 >>> The problem I see is that first you write "So any LCAF encoded = address >>> will have a minimum length of 8 bytes when the Length field is 0." = and >>> then you write "then the encoded address will have a minimum length = of >>> 6 bytes when the Length field is 0." I understand what you mean, but = I >>> feel this is a bit confusing. >>>=20 >>> Maybe you could say something like: >>>=20 >>> When including the AFI, an LCAF encoded address will have a minimum >>> length of 8 bytes when the Length field is 0. Or start by saying = that >>> the minimal length is 6, and then say that it will then be 8 when = the >>> AFI is included. >>=20 >> Changed to add your suggestion. Thanks. >>=20 >>>>> Section 4.10 >>>>> In this section there are several examples of using the AFI List = Type, >>>>> but I miss a general definition. It appears that there can be a = variable >>>>> number of AFIs in the list. Any number > 0? It might be useful to = have >>>>=20 >>>> Yes, a variable number. >>>=20 >>> How about adding a few lines of text to 4.10 saying that you can = have >>> a variable number etc., explaining briefly what the general format = is. >>> And then say that what follows are examples? >>=20 >> Done. >>=20 >>> Section 4.10.3 >>>>> Isn't it unusual to include the 0 termination? Since you know the >>>>> length it is not really needed. When parsing one will need to = check >>>>> the length either way, what should one do it the string = accidentally >>>>> is not 0-terminated? >>>>=20 >>>> Well the AFI definition in [AFI] doesn=E2=80=99t say how to = terminate the string. But the length field will imply it. However, I = wrote the =E2=80=9Cdistinguished-name=E2=80=9D draft to specify when = AFI=3D17 is used (not only in a LCAF but by itself), how to terminate = the string. I could include that reference, but that draft is not a = working group document. >>>>=20 >>>> So please advise. >>>=20 >>> Currently it says: >>>=20 >>> Length value n: length in bytes AFI=3D17 field and the = null-terminated >>> ASCII string (the last byte of 0 is included). >>>=20 >>> It might make sense to 0 terminate the DN in some cases, but at = least >>> here we know the string length from the value of n, so I think it >>> would be better to drop it here. And as I mentioned, you cannot rely >>> on the 0 for parsing, to be on the safe side you would use n anyway. >>=20 >> You want to terminate the string in all cases. Because there are = cases where AFI=3D17 is not used inside an LCAF encoding. And where = there is no length to convey the string length. And the = Distinguished-Name use-case Internet Draft specs this for both LCAF and = non-LCAF applications. >>=20 >>>>> Section 7 >>>>> It looks like the table in the IANA considerations doesn't include = all >>>>> the types defined in this document. >>>>=20 >>>> That was done intentionally. The ones that are experimental are not = in this section 7 list because there is no use-case document for it yet. = Maybe the chairs can explain this better than me. >>>=20 >>> I think it's still useful. If someone sees the type used, they can >>> look it up in the registry. It also helps avoid that someone perhaps >>> tries to reuse one of these types in new documents. If you really = want >>> to use one of the code points for something else in the future, a = new >>> document could always update the registry. >>=20 >> Did Luigi=E2=80=99s response satisfy your comment? >>=20 >>> BTW, it also makes me wonder if it is worth reserving any LCAF types >>> for experiments. >>=20 >> The space is large enough for FCFS. >>=20 >>> Regards, >>> Stig >>=20 >> See new version enclosed. Let me know when I can post it if you like = the changes. >>=20 >> Thanks again, >> Dino >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From nobody Tue Sep 20 07:31:37 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D2D12B943; Tue, 20 Sep 2016 07:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316] 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 1se2TjaOEqeN; Tue, 20 Sep 2016 07:31:31 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE48B12B7EA; Tue, 20 Sep 2016 07:20:02 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 20 Sep 2016 16:19:58 +0200 X-IronPort-AV: E=Sophos;i="5.30,368,1470693600"; d="scan'208";a="966612719" Received: from he101655.emea1.cds.t-internal.com ([10.134.226.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2016 16:19:58 +0200 Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101655.emea1.cds.t-internal.com (10.134.226.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Sep 2016 16:19:57 +0200 Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1210.000; Tue, 20 Sep 2016 16:19:57 +0200 From: To: , Thread-Topic: RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 Thread-Index: AQHSC5Z9pyMB30WX0E2E8+f1R3VI6aCCcYkg Date: Tue, 20 Sep 2016 14:19:57 +0000 Message-ID: <0d94e2cd77f34749b688fd4f8e3e7f8e@HE101653.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.157.171.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-tsvwg-diffserv-intercon.all@ietf.org, tsvwg@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 14:31:34 -0000 SGkgTG91LA0KDQp0aGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBmZWVkYmFjay4gTXkgcmVzcG9u c2UgdG9vayBhIGZldyBkYXlzIChJIHRyaWVkIHRvIGNvb3JkaW5hdGUgd2l0aCBEYXZpZCwgYnV0 IGZhaWxlZCB0byByZWFjaCBoaW0pLg0KDQpJIHdpbGwgY2hhbmdlIHRoZSBkb2N1bWVudCBpbiBz ZXZlcmFsIHBhcnRzIHRyeWluZyB0byBmb2xsb3cgeW91ciBndWlkYW5jZS4gSSdkIGxpa2UgdG8g ZGlzY3VzcyB5b3VyIGNvbW1lbnQgcmVsYXRlZCB0byBzZWN0aW9uIDIuDQoNClRoZSBJbnRyb2R1 Y3Rpb24gbWVudGlvbnMgU2hvcnQtUGlwZSBhbmQgc2F5cyBEaWZmc2Vydi1pbnRlcmNvbiBpcyB1 c2VmdWwgZm9yIGl0LiBJIGRvbid0IHRoaW5rIHRoZSBsYXR0ZXIgaW50cm9kdWNlcyBNUExTIFNo b3J0IFBpcGUgdG8gYSByZWFkZXIgaWYgaXQgaXNuJ3Qgb3BlcmF0aW9uYWwgaW4gaGlzIG93biBu ZXR3b3JrLiBPbmUgb2YgdGhlIGltcGxpY2F0aW9ucyBvZiBNUExTIFNob3J0IFBpcGUgZm9yIG5v biB0dW5uZWxlZCBJUCBpcyByZXdyaXRlIERTQ1AgdW5rbm93biB0byB6ZXJvIGF0IHRoZSBuZXR3 b3JrIEluZ3Jlc3MuIE5vbi10dW5uZWxlZCBpcyBkaXN0aW5ndWlzaGVkIGZyb20gdHVubmVsZWQg SVAgKGNvdWxkIGJlIGFuIElQLXR1bm5lbCwgY291bGQgYmUgSVAgdHJhZmZpYyByb3V0ZWQgdmlh IGFuIElQIG92ZXIgTVBMUyBWUE4pLiBTaG91bGQgd2UgYWRkIGFuIGV4cGxhbmF0aW9uIG9mICJu b24tdHVubmVsZWQgSVAiPw0KDQpNUExTIFNob3J0IFBpcGUgdXNlIGFjY29yZGluZyB0byBSRkMz MjcwIGFuZCBoZXJlIGZvciB0aGUgbm9uLXR1bm5lbGVkIElQIHRyYWZmaWMgaXMgYXMgZm9sbG93 cywgSSB0aGluayAoWCwgWSwgWiBpbmRpY2F0ZSBEaWZmU2VydiBEb21haW5zLCBJUiBhbmQgRVIg SW5ncmVzcyBSb3V0ZXIgYW5kIEVncmVzcyBSb3V0ZXIsIFBMU1IgUGVuLXVsdGltYXRlIExTUik6 DQoNClggLSBbSVJdIC0gWSAtIFtQTFNSXSAtIFkgRm9yd2FyZGluZywgWCBEU0NQIC0gW0VSXSAt IFgNCiAgICAgICAgICAgICAgICAgICAgICAtIFkgRm9yd2FyZGluZywgWSBEU0NQIC0gW0VSXSAt IFkNCg0KQ2FwaXRvbCBsZXR0ZXIgYWxvbmU6IEZvcndhcmRpbmcgYW5kIE1QTFMgVEMvRFNDUCBy ZXNwZWN0aXZlbHkgb2YgdGhhdCBkb21haW4uDQoNCkRpZmZzZXJ2LUludGVyY29uIGlzIGNsb3Nl IHRvIHRoYXQuIExldCdzIGFkZCBEaWZmc2Vydi1pbnRlcmNvbidzIEQgRFNDUCBhbmQgYXNzdW1l IHRoYXQgZWFjaCBkb21haW4gb3BlcmF0ZXMgdGhlIERpZmZzZXJ2LWludGVyY29uIFBIQnMgYnkg YW4gb3duIGRvbWFpbiBmbGF2b3VyOg0KDQpYIEZvcndhcmRpbmcsIEQgRFNDUCAtIFtJUl0gLSBZ IC0gW0VSXSAtIFkgRm9yd2FyZGluZywgRCBEU0NQDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgLSBZIC0gW0VSXSAtIFkgDQoNClJlcGxhY2UgIkQgRFNDUCIgYnkgIlggRFNDUCIgLT4gYSBz aW1pbGFyaXR5IHdpdGggUkZDMzI3MCBhcyBvcmlnaW5hbGx5IGRlc2lnbmVkIGlzIHZpc2libGUu DQoNClRha2luZyBlYWNoIGxpbmUgb2YgdGhlIGV4YW1wbGUgYXMgYW4gb3B0aW9uIGZvciBhIHJl YWxpemF0aW9uLCBib3RoIGNhc2VzIGFyZSBwb3NzaWJsZSBhbmQgaW50ZXJvcGVyYWJsZSBpbiB0 aGUgRGlmZnNlcnYtaW50ZXJjb24gY2FzZS4NCg0KSSB0aG91Z2h0LCBhIHNlcGFyYXRlIHNlY3Rp b24gaXMgdXNlZnVsIHRvIGluZGljYXRlIHdoeSB0aGVyZSdzIGEgcmV3cml0ZSBvZiB0aGUgaW5j b21pbmcgRFNDUCBmb3Igbm9uLXR1bm5lbGVkIElQIGF0IHRoZSBpbmdyZXNzLiBEZXV0c2NoZSBU ZWxla29tIGRvZXNuJ3Qgc3VwcG9ydCB0aGUgZmlyc3QgbGluZSBzaG93aW5nIFNob3J0IFBpcGUg YXMgc3BlY2lmaWVkIGJ5IFJGQzMyNzAuIFRoZSBMRVJzIGRvIG5vdCBoYW5kbGUgdHJhZmZpYyB3 aXRoIERTQ1BzIG9mIGRvd25zdHJlYW0gbmV0d29ya3MuIERpZmZzZXJ2LWludGVyY29uIG9mZmVy cyBhIGtpbmQgb2YgcmVwbGFjZW1lbnQgaGVyZS4NCg0KUmVnYXJkcywgUnVlZGlnZXINCg0KLS0t LS1NZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0 XSANCm1haWxlZDogU2Ftc3RhZywgMTAuIFNlcHRlbWJlciAyMDE2IDIxOjAwDQpUbzogcnRnLWFk c0BpZXRmLm9yZw0KQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHN2d2ctZGlmZnNl cnYtaW50ZXJjb24uYWxsQGlldGYub3JnOyB0c3Z3Zw0KU3ViamVjdDogUnRnRGlyIHJldmlldzog ZHJhZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vydi1pbnRlcmNvbi0wOQ0KDQpbc25pcF0NCg0KTWlub3Ig SXNzdWVzOg0KDQpbc25pcF0NCg0KLSBJbnRlbnQgb2Ygc2VjdGlvbiAyDQoNCkkgZm91bmQgdGhl IHB1cnBvc2Ugb2YgU2VjdGlvbiAyIGVudGlyZWx5IHVuY2xlYXIuICBUaGlzIG1heSBoYXZlIGJl ZW4gZHVlIHRvIHNvbWUgb2YgdGhlIGNvbmZ1c2luZyB0ZXh0IGl0IGNvbnRhaW5zIChlLmcuLCAg dGhlIDNyZCBzZW50ZW5jZSBvZiB0aGUgU2VjdGlvbiAtIHdoYXQgaXMgbm9uLXR1bm5lbGVkIElQ IHRyYWZmaWMgaW4gYW4gTVBMUyBuZXR3b3JrLCBhbmQgd2h5IHdvdWxkIGFuIE1QTFMgcHJvdmlk ZXIgYmUgdHVubmVsaW5nIHRyYWZmaWMgaW4gSVAgdHVubmVscz8pDQoNCklmIGl0J3MgbWVyZWx5 IHRvIGludHJvZHVjZSBNUExTIFNob3J0IFBpcGUncyBhbmQgUEhQLCB0aGVuIHRoaXMgaXMgYWNj b21wbGlzaGVkIGluIHNlY3Rpb24gMSAtLSBhbmQgYnkgUkZDMzI3MCBpdHNlbGYuICBJZiB0aGlz IGlzIHRoZSBzb2xlIHB1cnBvc2UsIHRoYW4gcGVyaGFwcyBpdCB3b3VsZCBiZSBlYXNpZXN0L2Jl c3QgdG8ganVzdCBkZWxldGUgdGhlIHNlY3Rpb24gb3IgY29tYmluZSBpdCB3aXRoIEFwcGVuZGl4 IEEuICBJZiB0aGVyZSBpcyBhbm90aGVyIHB1cnBvc2UgdGhhdCBpcyBjb3JlIHRvIHRoZSBkb2N1 bWVudCwgSSB0aGluayB0aGUgdGV4dCBuZWVkcyB0byBiZSByZXZpc2VkIHRvIG1ha2UgdGhhdCBw dXJwb3NlIGNsZWFyLA0KDQpbc25pcF0NCg0K From nobody Tue Sep 20 19:14:30 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0298212B178; Tue, 20 Sep 2016 19:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=OAAdlJa/; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=gL/1y6YX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RwK2Lnykf_W; Tue, 20 Sep 2016 19:14:25 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 3CA7812B177; Tue, 20 Sep 2016 19:14:25 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:2:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=e3DCm+q6fEXzYdBVMfIzsPvUf7e2IhhEjp8YF2SYPjYRCOsbcbRkOQxg uE4LVjsgE0YyQXV49CuBfw6BjJHSi0qqu4Q5/yHIROyaxMg0IVHtmI16v bfjRve2sMuF2DJsLcdiaHkzQg+MtEySgJaAJTLhs53LUUhN3TYMFt0R5j Q=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1474424065; x=1505960065; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H4lb4MhOwUplAcnCxOD3ZhKD2v8POHWMcvnxcaHdlsk=; b=OAAdlJa/F5ucugNv8PU5VOoNux3j6D5TdBHavQiyMYIm0wZ0BUJD3I76 DDmgoVL0tfOpDJrwCrC3BGXploPIxGdZhc6gzY1m9Su/YK6P5X+FE8dmF C0u9wdkycgvuYxe+zWB8DT42fJBDcFl3wgltYEfbCEMWGF9NrNK8uGW/G E=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2016 21:14:24 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2016 08:14:22 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8L2EH9R001175 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Sep 2016 22:14:20 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u8L2EH9R001175 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1474424060; bh=UVllWrGS2yHuA6PzvGVft0pQczU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=gL/1y6YXuSUJh5+OVUpI4R0wt4C6EULNVLYQ2roOjf1iyY4ZV1gfPW9kiMVE0md94 aWeY7nOJNMzP8etXSbd8KJs53MffPi84OnpFRg+P9ho/koAwHaD2lhGbYCNL87tR4y +j0rr7eCKjIMucNTZ5sohI0viZVycPlpS8oQmMNs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com u8L2EH9R001175 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd01.lss.emc.com (RSA Interceptor); Tue, 20 Sep 2016 22:13:54 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8L2EC3C011624 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 20 Sep 2016 22:14:12 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0266.001; Tue, 20 Sep 2016 22:14:12 -0400 To: Lou Berger , "rtg-ads@ietf.org" Thread-Topic: RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 Thread-Index: AQHSC5Z+EMftoXXCCkK62DPK7sfJpaCDOrag Date: Wed, 21 Sep 2016 02:14:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.97.22.193] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-tsvwg-diffserv-intercon.all@ietf.org" , tsvwg , "Black, David" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 02:14:28 -0000 TG91LA0KDQpbQ29tbWVudGluZyBhcyBhIGRyYWZ0IGF1dGhvciwgbm90IFdHIGNoYWlyXQ0KDQpU aGFua3MgZm9yIHRoZSByZXZpZXcsIGFuZCBzb3JyeSBmb3IgdGhlIGRlbGF5ZWQgcmVzcG9uc2Ug IC0gRU1DIGlzIG5vdyBwYXJ0DQpvZiBEZWxsLCBhbmQgbXkgbGlmZSdzIGJlZW4gImludGVyZXN0 aW5nIiBhcyBhIHJlc3VsdCAuLi4NCg0KUnVlZGlnZXIncyBjb21tZW50ZWQgb24geW91ciBTZWN0 aW9uIDIgY29uY2Vybiwgc28gSSdsbCBwaWNrIHVwIHRoZSBvdGhlcg0KdHdvIG1pbm9yIGlzc3Vl cywgYW5kIGFkZCBzb21lIG1vcmUgY29tbWVudGFyeSBvbiBTZWN0aW9uIDIgLi4uDQoNCj4gLSBU aGUgZmlyc3QgaXNzdWUgaXMgdGFyZ2V0IHVzZSAvIGFwcGxpY2FiaWxpdHkNCj4gDQo+IFRoZSBk b2N1bWVudCB0aXRsZSBpbXBsaWVzIHRoYXQgdGhlIGRvY3VtZW50IHNjb3BlIG1heSBhcHBseSB0 byBhbnkNCj4gcHJvdmlkZXIgaW50ZXJjb25uZWN0aW9uIGFzIGRvZXMgMXN0IHNlbnRlbmNlIG9m IHRoZSAzcmQgcGFyYWdyYXBoIDMgb2YNCj4gc2VjdGlvbiAxOyBJUCB0dW5uZWxzIGFyZSBhbHNv IG1lbnRpb25lZCBpbiBTZWN0aW9uIDQuMy4gWWV0IHRoZQ0KPiBBYnN0cmFjdCBhbmQgU2VjdGlv biAxLjIgc3RhdGUgYXBwbGljYWJpbGl0eSBpcyB0byBNUExTLWJhc2VkIHByb3ZpZGVycy4NCg0K QXBwbGljYWJpbGl0eSBpcyB0byBhbnkgcHJvdmlkZXIgaW50ZXJjb25uZWN0aW9uLCB3aXRoIHN1 aXRhYmlsaXR5IGZvcg0KTVBMUy1iYXNlZCBwcm92aWRlcnMgYmVpbmcgYSBzaWduaWZpY2FudCBk ZXNpZ24gZ29hbC9yYXRpb25hbGUsIGR1ZSB0bw0KdGhlIGxpbWl0ZWQgbnVtYmVyIG9mIGJpdHMv dmFsdWVzIGF2YWlsYWJsZSBmb3IgRGlmZnNlcnYgaW4gYW4gTVBMUyBsYWJlbC4NCg0KPiAgU2Vj dGlvbiA0IHRoZW4gZnVydGhlciBuYXJyb3dzIGFwcGxpY2FiaWxpdHkgNCBjbGFzc2VzIG9mIHRy YWZmaWMuDQoNClRoYXQgZGVmaW5pdGVseSBuZWVkcyBlZGl0aW5nIGF0dGVudGlvbiwgYXMgdGhl IDQgYWdncmVnYXRlZCBjbGFzc2VzDQpvZiB0cmFmZmljIGFyZSB0aGUgY29yZSBvZiB0aGUgZGVz aWduIC0gYWxtb3N0IGFueSBuZXR3b3JrIHRyYWZmaWMgY2FuDQpiZSBjYXJyaWVkIHZpYSBhbiBp bnRlcmNvbm5lY3Rpb24gdXNpbmcgdGhlIHN0cnVjdHVyZSBkZXNjcmliZWQgaW4gdGhpcw0KZHJh ZnQuICBBbGwgb2YgdGhlIHRyYWZmaWMgY2xhc3NlcyBkZWZpbmVkIGluIFJGQyA0NTk0IGhhdmUg YmVlbg0KY292ZXJlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgYWdncmVnYXRlcy4NCg0K PiAtIFVzZSBvZiAgJ1FvUycNCj4gDQo+IEkgZmluZCBRb1MgdW5kZWZpbmVkIGluIHRoZSBkb2N1 bWVudCBhbmQgaXMgcmVhbGx5IGJlaW5nIHVzZWQNCj4gc3lub255bW91c2x5IHdpdGggJ3RyYWZm aWMgY2xhc3MnLCAndHJhZmZpYyB0cmVhdG1lbnQnLCAnRFNDUCcsICdDbGFzcw0KPiBvZiBTZXJ2 aWNlJyBhbmQgZXZlbiBEaWZmU2VydiBpdHNlbGYgaW4gdGhlIGRvY3VtZW50LiAgSSB0aGluayB0 aGUNCj4gaW50ZW50IGFuZCBjbGFyaXR5IG9mIHRoZSBkb2N1bWVudCB3b3VsZCBiZSBpbXByb3Zl ZCBieSByZW1vdmluZyBvcg0KPiByZXBsYWNpbmcgYWxsIGluc3RhbmNlcyBvZiBRb1MuICBUaGlz IHdvdWxkIG9idmlhdGUgbmVlZGluZyB0byBkZWZpbmUNCj4gd2hhdCBRb1MgbWVhbnMgaW4gdGhl IGNvbnRleHQgb2YgdGhlIHNwZWNpZmljIChhbmQgbGltaXRlZCkgdXNhZ2Ugb2YNCj4gRGlmZlNl cnYsIGFzIHdlbGwgYXMgYXZvaWQgbmFtaW5nIGNvbnNpc3RlbmN5IHdpdGggb3RoZXIgZG9jdW1l bnRzLg0KDQpPaywgd2UnbGwgYXQgbGVhc3QgZ3JlYXRseSByZWR1Y2UgdXNlICBvZiAiUW9TIiBv ciBlbGltaW5hdGUgaXQgZW50aXJlbHkuDQoNCj4gLSBJbnRlbnQgb2Ygc2VjdGlvbiAyDQo+IA0K PiBJIGZvdW5kIHRoZSBwdXJwb3NlIG9mIFNlY3Rpb24gMiBlbnRpcmVseSB1bmNsZWFyLg0KDQpb Li4uIHNuaXAgLi4uXQ0KIA0KPiBJZiBpdCdzIG1lcmVseSB0byBpbnRyb2R1Y2UgTVBMUyBTaG9y dCBQaXBlJ3MgYW5kIFBIUCwgdGhlbiB0aGlzIGlzDQo+IGFjY29tcGxpc2hlZCBpbiBzZWN0aW9u IDEgLS0gYW5kIGJ5IFJGQzMyNzAgaXRzZWxmLiAgDQoNCk5vcGUsIFNlY3Rpb24gMidzIHB1cnBv c2UgaXMgdG8gb3V0bGluZSB0aGUgY29uc3RyYWludHMgb24gdGhlIGRlc2lnbg0Kc3BhY2UgdGhh dCBsZWFkIHRvIHdoYXQgd2UgZGlkLiAgRGlmZnNlcnYgdHVubmVsaW5nIGlzIGRlc2NyaWJlZCBp bg0KUkZDIDI5ODMsIHdoZXJlIHRoZSB0dW5uZWwgaGVhZGVyIGlzIHJlbW92ZWQgYXQgdGhlIHR1 bm5lbCBlZ3Jlc3MsDQpzbyB0d28gRFNDUCB2YWx1ZXMgYXJlIGF2YWlsYWJsZSB0byB0aGUgdHVu bmVsIGVncmVzcyBub2RlLiAgIE1QTFMNCnNob3J0IHBpcGUncyB1c2Ugb2YgUEhQIChhcyBkZXNj cmliZWQgaW4gUkZDIDMyNzApIGRlcGFydHMgZnJvbSBSRkMgMjk4Mw0Kd2l0aCB0aGUgcmVzdWx0 IHRoYXQgb25seSBvbmUgdXNhYmxlIERTQ1AgdmFsdWUgaXMgYXZhaWxhYmxlIHRvIHRoZSB0dW5u ZWwNCmVncmVzcyBub2RlLiAgIEV4cGxhaW5pbmcgdGhhdCBhbmQgdGhlIHJlc3VsdGluZyBkZXNp Z24gcmVzdHJpY3Rpb25zDQppcyB0aGUgcHJpbWFyeSBwdXJwb3NlIG9mIFNlY3Rpb24gMiwgc2Vl IHRoZSBsYXN0IHBhcmFncmFwaCBpbiB0aGF0DQpzZWN0aW9uIC0gdGhpcyBpcyBuZWVkZWQgdG8g bWFrZSB0aGUgZHJhZnQgYWNjZXNzaWJsZSB0byB0aG9zZSB3aG8NCmFyZW4ndCBNUExTIGV4cGVy dHMuDQoNCkFsb25nIHRoZSB3YXksIGl0IHdhcyBhbHNvIG5lY2Vzc2FyeSB0byBkaXNtaXNzIFJG QyAyNDc0J3MNCnJlY29tbWVuZGF0aW9uIHRvICJmb3J3YXJkIHRyYWZmaWMgd2l0aCB1bnJlY29n bml6ZWQgRFNDUHMNCndpdGggRGVmYXVsdCAoYmVzdCBlZmZvcnQpIHNlcnZpY2Ugd2l0aG91dCBy ZXdyaXRpbmcgdGhlIERTQ1AiDQphcyBwb29yIG9wZXJhdGlvbmFsIHByYWN0aWNlIGFuZCBmb2N1 cyBvbiB0cmFmZmljIHRoYXQgZG9lcyBub3QNCnVzZSBhIHByb3ZpZGVyLXByb3Zpc2lvbmVkIElQ IHR1bm5lbCBhY3Jvc3MgdGhlIHByb3ZpZGVyJ3MNCm5ldHdvcmsuICBUaGVzZSBjb25zdHJhaW50 cyBwbHVzIE1QTFMgc2hvcnQtcGlwZSBQSFANCnNldmVyZWx5IGxpbWl0IHRoZSBkZXNpZ24gc3Bh Y2UuDQoNClRoYW5rcywgLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiBTYXR1 cmRheSwgU2VwdGVtYmVyIDEwLCAyMDE2IDM6MDAgUE0NCj4gVG86IHJ0Zy1hZHNAaWV0Zi5vcmcN Cj4gQ2M6IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHN2d2ctZGlmZnNlcnYtaW50ZXJj b24uYWxsQGlldGYub3JnOyB0c3Z3Zw0KPiBTdWJqZWN0OiBSdGdEaXIgcmV2aWV3OiBkcmFmdC1p ZXRmLXRzdndnLWRpZmZzZXJ2LWludGVyY29uLTA5DQo+IA0KPiBIZWxsbywNCj4gDQo+IEkgaGF2 ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0 aGlzIGRyYWZ0Lg0KPiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxs IHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3Vn aCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZA0KPiBzb21ldGltZXMgb24gc3Bl Y2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUNCj4g YXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBSb3V0aW5nDQo+IERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo+IOKAi2h0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gDQo+IEFsdGhvdWdo IHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcg QURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFs b25nIHdpdGggYW55IG90aGVyIElFVEYNCj4gTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJl Y2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2gNCj4gZGlzY3Vzc2lvbiBv ciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi10c3Z3 Zy1kaWZmc2Vydi1pbnRlcmNvbi0wOQ0KPiBSZXZpZXdlcjogTG91IEJlcmdlcg0KPiBSZXZpZXcg RGF0ZTogU2VwdCAxMA0KPiBJbnRlbmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWwNCj4gDQo+IFN1 bW1hcnk6DQo+IA0KPiAgICAgSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBk b2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkDQo+IGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNh dGlvbi4NCj4gDQo+IENvbW1lbnRzOg0KPiANCj4gVGhpcyBkb2N1bWVudCBpcyBiZWluZyBwdWJs aXNoZWQgYXMgSW5mb3JtYXRpb25hbCBhcyBzdWNoIG15IHJldmlldyBhbmQNCj4gY29tbWVudHMg Zm9jdXMgbW9yZSBvbiB0aGUgY2xhcml0eSBvZiB0aGUgZG9jdW1lbnQgdGhhbiBpdHMgc3BlY2lm aWMNCj4gcmVjb21tZW5kYXRpb25zLiAgV2hpbGUgdGhlIGRvY3VtZW50IGhhcyBubyBtYWpvciBp c3N1ZXMsIEkgdGhpbmsgdGhlDQo+IGN1cnJlbnRseSBoYXMgYSBudW1iZXIgb2YgY29uZnVzaW5n LCBpZiBub3QgY29udHJhZGljdG9yeSwgc3RhdGVtZW50cw0KPiB0aGF0IHNob3VsZCBiZSBjbGFy aWZpZWQgcHJpb3IgdG8gcHVibGljYXRpb25zLiAgVGhlcmUgYXJlIGFsc28gYSBudW1iZXINCj4g b2Ygb3RoZXIgaXNzdWVzLCByYW5naW5nIGZyb20gbWlub3IgIHRvIG5pdCAtIGxldmVsLCB0aGF0 IHNob3VsZCBhbHNvIGJlDQo+IGFkZHJlc3NlZC4NCj4gDQo+IA0KPiBNYWpvciBJc3N1ZXM6DQo+ IA0KPiAJTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KPiANCj4gTWlub3IgSXNzdWVzOg0KPiANCj4g LSBUaGUgZmlyc3QgaXNzdWUgaXMgdGFyZ2V0IHVzZSAvIGFwcGxpY2FiaWxpdHkNCj4gDQo+IFRo ZSBkb2N1bWVudCB0aXRsZSBpbXBsaWVzIHRoYXQgdGhlIGRvY3VtZW50IHNjb3BlIG1heSBhcHBs eSB0byBhbnkNCj4gcHJvdmlkZXIgaW50ZXJjb25uZWN0aW9uIGFzIGRvZXMgMXN0IHNlbnRlbmNl IG9mIHRoZSAzcmQgcGFyYWdyYXBoIDMgb2YNCj4gc2VjdGlvbiAxOyBJUCB0dW5uZWxzIGFyZSBh bHNvIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQuMy4gWWV0IHRoZQ0KPiBBYnN0cmFjdCBhbmQgU2Vj dGlvbiAxLjIgc3RhdGUgYXBwbGljYWJpbGl0eSBpcyB0byBNUExTLWJhc2VkIHByb3ZpZGVycy4N Cj4gIFNlY3Rpb24gNCB0aGVuIGZ1cnRoZXIgbmFycm93cyBhcHBsaWNhYmlsaXR5IDQgY2xhc3Nl cyBvZiB0cmFmZmljLg0KPiANCj4gSSB0aGluayB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlzIGRv Y3VtZW50IHRvIGJvdGggKGEpIGludHJhLXByb3ZpZGVyDQo+IHRlY2hub2xvZ2llcyBhbmQgKGIp IHN1cHBvcnRlZCB0cmFmZmljIGNsYXNzZXMgbmVlZCB0byBiZSBjbGFyaWZpZWQgYW5kDQo+IGNv bnNpc3RlbnQgYWNyb3NzIHRoZSBkb2N1bWVudCdzIFRpdGxlLCBBYnN0cmFjdCwgSW50cm8vQXBw bGljYWJpbGl0eQ0KPiBhbmQgb3RoZXIgc2VjdGlvbnMuDQo+IA0KPiAtIFVzZSBvZiAnUW9TJw0K PiANCj4gSSBmaW5kIFFvUyB1bmRlZmluZWQgaW4gdGhlIGRvY3VtZW50IGFuZCBpcyByZWFsbHkg YmVpbmcgdXNlZA0KPiBzeW5vbnltb3VzbHkgd2l0aCAndHJhZmZpYyBjbGFzcycsICd0cmFmZmlj IHRyZWF0bWVudCcsICdEU0NQJywgJ0NsYXNzDQo+IG9mIFNlcnZpY2UnIGFuZCBldmVuIERpZmZT ZXJ2IGl0c2VsZiBpbiB0aGUgZG9jdW1lbnQuICBJIHRoaW5rIHRoZQ0KPiBpbnRlbnQgYW5kIGNs YXJpdHkgb2YgdGhlIGRvY3VtZW50IHdvdWxkIGJlIGltcHJvdmVkIGJ5IHJlbW92aW5nIG9yDQo+ IHJlcGxhY2luZyBhbGwgaW5zdGFuY2VzIG9mIFFvUy4gIFRoaXMgd291bGQgb2J2aWF0ZSBuZWVk aW5nIHRvIGRlZmluZQ0KPiB3aGF0IFFvUyBtZWFucyBpbiB0aGUgY29udGV4dCBvZiB0aGUgc3Bl Y2lmaWMgKGFuZCBsaW1pdGVkKSB1c2FnZSBvZg0KPiBEaWZmU2VydiwgYXMgd2VsbCBhcyBhdm9p ZCBuYW1pbmcgY29uc2lzdGVuY3kgd2l0aCBvdGhlciBkb2N1bWVudHMuDQo+IA0KPiAtIEludGVu dCBvZiBzZWN0aW9uIDINCj4gDQo+IEkgZm91bmQgdGhlIHB1cnBvc2Ugb2YgU2VjdGlvbiAyIGVu dGlyZWx5IHVuY2xlYXIuICBUaGlzIG1heSBoYXZlIGJlZW4NCj4gZHVlIHRvIHNvbWUgb2YgdGhl IGNvbmZ1c2luZyB0ZXh0IGl0IGNvbnRhaW5zIChlLmcuLCAgdGhlIDNyZCBzZW50ZW5jZQ0KPiBv ZiB0aGUgU2VjdGlvbiAtIHdoYXQgaXMgbm9uLXR1bm5lbGVkIElQIHRyYWZmaWMgaW4gYW4gTVBM UyBuZXR3b3JrLCBhbmQNCj4gd2h5IHdvdWxkIGFuIE1QTFMgcHJvdmlkZXIgYmUgdHVubmVsaW5n IHRyYWZmaWMgaW4gSVAgdHVubmVscz8pDQo+IA0KPiBJZiBpdCdzIG1lcmVseSB0byBpbnRyb2R1 Y2UgTVBMUyBTaG9ydCBQaXBlJ3MgYW5kIFBIUCwgdGhlbiB0aGlzIGlzDQo+IGFjY29tcGxpc2hl ZCBpbiBzZWN0aW9uIDEgLS0gYW5kIGJ5IFJGQzMyNzAgaXRzZWxmLiAgSWYgdGhpcyBpcyB0aGUg c29sZQ0KPiBwdXJwb3NlLCB0aGFuIHBlcmhhcHMgaXQgd291bGQgYmUgZWFzaWVzdC9iZXN0IHRv IGp1c3QgZGVsZXRlIHRoZQ0KPiBzZWN0aW9uIG9yIGNvbWJpbmUgaXQgd2l0aCBBcHBlbmRpeCBB LiAgSWYgdGhlcmUgaXMgYW5vdGhlciBwdXJwb3NlIHRoYXQNCj4gaXMgY29yZSB0byB0aGUgZG9j dW1lbnQsIEkgdGhpbmsgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmV2aXNlZCB0byBtYWtlDQo+IHRo YXQgcHVycG9zZSBjbGVhciwNCj4gDQo+IA0KPiBOaXRzOg0KPiANCj4gLSBUaGUgZG9jdW1lbnQg aXMgaW5jb25zaXN0ZW50IGluIGhvdyBpdCByZWZlcmVuY2VzIFJGQ3MuICBBdCB0aW1lcywgaXQN Cj4gZXhwYW5kcyB0aGUgUkZDIGFzIHRleHQgKGUuZy4sICJSRkMgMjQ3NSIpIG90aGVyIHRpbWVz IGl0IHVzZXMgcmVmZXJlbmNlDQo+IG5vdGF0aW9uIChlLmcuLCBbUkZDNTEyN10pIG90aGVyIHRp bWVzIGl0IHVzZXMgYm90aCAoZS5nLCBSRkMgNTEyNw0KPiBbUkZDNTEyN10pLiAgU29tZSBjb25z aXN0ZW5jeSBvbiB1c2UgLyBpbnRlbnQgd291bGQgYmVuZWZpdCB0aGUgZG9jdW1lbnQuDQo+IA0K PiANCg0K From nobody Thu Sep 22 08:01:23 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A3612B0FB; Thu, 22 Sep 2016 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 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_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzhMDOAtXyB2; Thu, 22 Sep 2016 08:01:19 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0134.outbound.protection.outlook.com [104.47.41.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C8F12B24A; Thu, 22 Sep 2016 08:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JK0x9g0CMoMIV6yPt3KBOEESPbnIW1hYxbnq5hS6E1U=; b=MVrkI2Q98psWmajFg+4/V2uR3MWb0JoSFsX3u/pJsbetAoH8y1RNdNbU0xM9vawzPFXjLO92QUGgLeJCK6zUypTAy3CTykU+HBI9bskxzgQWsdgiGQziiJN6HmIJrNVwRJB4C5tcEEL7CrAckns0IFs+kO77aYcVWHPSKCMSb8c= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.2; Thu, 22 Sep 2016 15:01:12 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0639.005; Thu, 22 Sep 2016 15:01:12 +0000 From: Ron Bonica To: "" Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-dual-homing-protection-04 Thread-Index: AdIU4ate9t5TA3/DSEysHewTYEvC7w== Date: Thu, 22 Sep 2016 15:01:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 7e475dd1-599d-4cfd-29c3-08d3e2f94b05 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 6:joW/rtQ0rfrx8H6vKAkSrwf4VOVwX16sWwKJU7XvY6B/lPKZA99iRAKSz4JEdkTkY1RwJHAyoLsV8WAoYCpxpSVMM6n1MH7EmF266SghDugP/MKuobuwgr8zNfX/y3bGqJo5IFcGdHw0N3K7ZmK2ordQLZQ287oJITnYGPWC+BdyT0utSx4OTeXO40d+9Kka0l5ZWCkkPL6EEN4jdrx4WQhRPfDLT9GfD7L2ny8OIBeV3+46+x1VwK1WVefPjbMERi9GIbcctDavRLGGTRda7i+ErhsImZ0Fj6tlcTrKNTitggxKx5G8WTDzw/MDOjUNevuK7EyxsdNzeaud3DExmw==; 5:y4U/I/nZ9cTXzwNgbmSI6dDdXfubeblosTYW342zuqNV2NSzLMT5Hh/Bi/QE0ydbZJLze8rpDyIAnVFgmCUT7DjeFc+7KPm7GllA2XygeRTKdT5RF5MhuchT385SP4mPwbPYP9dToRJScZyT2iWlbA==; 24:YXhB/QoLl6K10UmH0+I1l8S54B4S7xxqUyxb2x9dmIfFJG5d8VumXCvOzrDSiaWKAIJY9XV9oAtEuA2TqqPkXK4bsYkVVCsIxAGz1axOgkY=; 7:P2U6rugpcSqPi1+/xQbSowHM0ugpVQ6zAUpEku+hXnlCL4jLrI0bTwb+VhoGy60S2WEB/e9I5FfDdQXbP3R+Gwb6jgeLtLaUIgceRu50Q4+8rvY5F4PM11lDDXC7AyFqjv+ENs32RsJSXokih1aifHarcxTqcoZAgZ5bSY7dD3aYFjpUkdRN2rXByVgQ3frTkTp66MlubEmVhrUhm7LHnGPG+V3DZOqeaSEeIkTKXAlho8DgiU3Y0Aw8lMGsLVD6E16wqMirVPNoVUzKml9GgMhFktmJ6aagMFytrXp2J7RAHe4hmylTfHvz2Qz5KQ0A x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2049; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 0073BFEF03 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(110136003)(92566002)(81156014)(2906002)(74316002)(4326007)(3280700002)(33656002)(3660700001)(5002640100001)(7846002)(68736007)(7696004)(87936001)(106356001)(450100001)(305945005)(229853001)(7736002)(105586002)(99286002)(5660300001)(189998001)(3846002)(2900100001)(10400500002)(1720100001)(102836003)(66066001)(50986999)(122556002)(19580395003)(230783001)(86362001)(6116002)(77096005)(9686002)(81166006)(101416001)(76576001)(11100500001)(8936002)(97736004)(586003)(8676002)(54356999)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2016 15:01:12.1724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: Cc: "rtg-dir@ietf.org" , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-dual-homing-protection.all@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-dual-homing-protection-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 15:01:21 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLWR1YWwtaG9taW5n LXByb3RlY3Rpb24tMDQNClJldmlld2VyOiBSb24gQm9uaWNhDQpSZXZpZXcgRGF0ZTogMi8yMi8y MDE2DQpJRVRGIExDIEVuZCBEYXRlOiANCkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbA0K DQpTdW1tYXJ5OiANCg0KTm8gaXNzdWVzIGZvdW5kLiBUaGlzIGRvY3VtZW50IGlzIHJlYWR5IGZv ciBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQoNCk1ham9yIElzc3VlczoNCg0KTm9uZQ0KDQpN aW5vciANCg0KTm9uZQ0KDQpOaXRzOg0KDQpOb25lDQo= From nobody Thu Sep 22 08:32:22 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CDC12BB7F; Thu, 22 Sep 2016 08:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPzYIXZ5r9Qg; Thu, 22 Sep 2016 08:32:16 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1267812BB7D; Thu, 22 Sep 2016 08:32:16 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id r126so101727025oib.0; Thu, 22 Sep 2016 08:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CMWtAHy4dsaS4Y5v0L5S9GkwJR2sxzdmjkxwX0c7Bak=; b=ixFJyQheiKlM13uaDC7LeUukh1pOoGnWMm4Q/GXpTFPliVQHf2rUBDOEiwZxZ/0N1b 8BGL7tYETgCiuNQtLeOtDjZAWKZP1iwrBXz9gA0NSkuMeHwuhlw1FbhFMOUMnTA3ahwV ooGCeU69oRQJL+RPkl2L+QYQdWJjExK9WUl2GZ3HO3+fFZKS5pZqnsi+amwX6iNq3euC 2c5aFIRHbXdaHv9zbCpZHdUXLs1sGJYwNQRak9UGkokgXvkNZoycfxvfAP0hPpCcFieM Iq5XfjviHOyVDxKf4NDIRvsxqYIEh7wmrMss0mc4nSBofqmy1pzJOx4+wXwOtazpFEwP Q+Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CMWtAHy4dsaS4Y5v0L5S9GkwJR2sxzdmjkxwX0c7Bak=; b=Z5YE5+ttA7FeDnJsIsdx05kxiue30fqn4Fr5NVv+IGKJ0ieo/ali+OtYEex1xFRLkT 2Cq8q7HyYof6CcSOFGi9uZ9GIktRWcc/eXJJc0CaNr/uLt6DVH98iSo7zH1pfzNzzXgV R5n1FiUFFTrxI3Llun9aTMQoYUOuOjwDqjpdC/OUn65VDaOMnFKxKdsTnq8z8yopYNwB hiDAnWLUWbuQmsZx/9fUI7ELvBSLsah4K0qdqcEoVLFC52XUuB1f5MPbJVJwiwHy3hXK tC2CNYATQLeHlK9O9X3rEfvmsmrH/er+YLxrVIoZR7gwAybpba26isradsmX2/2IGcl6 hXww== X-Gm-Message-State: AE9vXwPITkPlxP/F5RnP/ovgQm6FMmtHf/1NOjyg0BUhwp/PK1aZFCOM+Q4TnHO8cq4EiOQVD1vXxMtQnjvM1Q== X-Received: by 10.202.219.215 with SMTP id s206mr3462538oig.6.1474558335386; Thu, 22 Sep 2016 08:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.247.71 with HTTP; Thu, 22 Sep 2016 08:31:55 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Thu, 22 Sep 2016 11:31:55 -0400 Message-ID: To: Ron Bonica Content-Type: multipart/alternative; boundary=001a113d4a98c80e3f053d1a5d61 Archived-At: Cc: "" , "rtg-dir@ietf.org" , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-dual-homing-protection.all@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-mpls-tp-dual-homing-protection-04 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 15:32:17 -0000 --001a113d4a98c80e3f053d1a5d61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ron, Thanks for your review! Cheers, Andy On Thu, Sep 22, 2016 at 11:01 AM, Ron Bonica 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, plea= se > 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 Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-pals-mpls-tp-dual-homing-protection-04 > Reviewer: Ron Bonica > Review Date: 2/22/2016 > IETF LC End Date: > Intended Status: Informational > > Summary: > > No issues found. This document is ready for publication. > > Comments: > > Major Issues: > > None > > Minor > > None > > Nits: > > None > --001a113d4a98c80e3f053d1a5d61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ron,

Thanks for your review!
=
Cheers,
Andy

On Thu, Sep 22, 2016 at 11:01 AM, Ron Bonic= a <rbonica@juniper.net> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing 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 wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

Document: draft-ietf-pals-mpls-tp-dual-homing-protection-04
Reviewer: Ron Bonica
Review Date: 2/22/2016
IETF LC End Date:
Intended Status: Informational

Summary:

No issues found. This document is ready for publication.

Comments:

Major Issues:

None

Minor

None

Nits:

None

--001a113d4a98c80e3f053d1a5d61-- From nobody Mon Sep 26 08:23:10 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2470712B125; Mon, 26 Sep 2016 08:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhgmyl3cIFm0; Mon, 26 Sep 2016 08:23:01 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0096.outbound.protection.outlook.com [104.47.41.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440A212B2B2; Mon, 26 Sep 2016 08:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=td5w0vEVBmclWOLP8fOLzLHNM+gtoJOnmr7lIcDZEzc=; b=JVAM9HknfHloscJ5V8VnaxtotpuglmOdSZ+1MVFxWp3U5aM4DfVkR3qnQyx9fy8BYrA3tyTEqdI8sMn9bYZgPpStOfFCpt3nN/b6OoOdk4XOsiIkjhx9xal1BPa9du2KI8z5i/r6yDecCtYA2PhSKxQp5QyM538C08JlD2w+i3g= Received: from BN6PR05MB2995.namprd05.prod.outlook.com (10.173.19.13) by BN6PR05MB2994.namprd05.prod.outlook.com (10.173.19.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.6; Mon, 26 Sep 2016 15:22:54 +0000 Received: from BN6PR05MB2995.namprd05.prod.outlook.com ([10.173.19.13]) by BN6PR05MB2995.namprd05.prod.outlook.com ([10.173.19.13]) with mapi id 15.01.0649.008; Mon, 26 Sep 2016 15:22:54 +0000 From: John E Drake To: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "pals@ietf.org" , "draft-ietf-pals-endpoint-fast-protection.all@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pals-endpoint-fast-protection-03 Thread-Index: AdIYCVtHojkMCz2DTHefc9cPDZY6sQ== Date: Mon, 26 Sep 2016 15:22:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net; x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: f40cfa17-a517-4537-c7d0-08d3e620fcd1 x-microsoft-exchange-diagnostics: 1; BN6PR05MB2994; 7:eokvwCX8WUsAbxcoYVYbbYxsvG/hq2xXeWsa0yC9cqkAf+gia+kJQhk9BrBDwoTfkAotCyRfFaZD5lU/Zkm669HzwgBH23ks362HnItgKwpJ1oKWLOsEnkufulofBnk+9JLQmlf1joiIWeRwfzEEtzX9MBE3aGWL6YMHnWIefHSHjiMopjdw6+EPEypoxnTn8eTg9kr5qtK9znkI/r/vmhnPY6pHrFAwZLdqIdACdP2h1+5C31j3X3jKYweMzb7IZ+dnHV3I6vw4T60kVc2NZZCy8zKGJ2aGQ8vh8wNk1IAtLeb+5qD8rD6VlOVzcVSH453GxWoe9ixCbYlQQuzSzQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR05MB2994; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN6PR05MB2994; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB2994; x-forefront-prvs: 00770C4423 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(81156014)(8676002)(99286002)(74316002)(76576001)(81166006)(68736007)(2906002)(2501003)(9686002)(92566002)(8936002)(10400500002)(3280700002)(122556002)(66066001)(86362001)(7846002)(87936001)(305945005)(7736002)(230783001)(3660700001)(2201001)(450100001)(2900100001)(189998001)(586003)(77096005)(15975445007)(107886002)(102836003)(50986999)(5660300001)(6116002)(3846002)(11100500001)(54356999)(7696004)(1720100001)(5002640100001)(229853001)(106356001)(105586002)(19580395003)(5001770100001)(33656002)(101416001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB2994; H:BN6PR05MB2995.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2016 15:22:54.3719 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2994 Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-pals-endpoint-fast-protection-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 15:23:03 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-pals-endpoint-fast-protection-03 Reviewer: John Drake Review Date: 09/23/2016 IETF LC End Date:=20 Intended Status: Standards Track Summary:=20 No issues found. This document is ready for publication. Comments: Major Issues: None Minor=20 None Nits: None Yours Irrespectively, John From nobody Mon Sep 26 08:48:11 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D2312B2E3 for ; Mon, 26 Sep 2016 08:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 XXb6rpH4N52x for ; Mon, 26 Sep 2016 08:48:08 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 90E5D12B2D9 for ; Mon, 26 Sep 2016 08:48:08 -0700 (PDT) Received: (qmail 25872 invoked by uid 0); 26 Sep 2016 15:48:05 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 26 Sep 2016 15:48:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id oFo11t00R2SSUrH01Fo4KT; Mon, 26 Sep 2016 09:48:04 -0600 X-Authority-Analysis: v=2.1 cv=aaryw3Yt c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=GW1xBdLrtEIA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=W1J57drHtcVx3WT3sNkA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=FJsJqcB7PMu73abwfp048qDkv4NrBb1vjOztsV6Wipk=; b=auTqyCIL45xrNb7wFs6WqmjSOp /8/6VkZfLMBHyvclA9YgOw6Af8RvIAfWGPIkN/L7l5uGCTJ8Oc6tUFlZDlbVkyPHlSwRAW1/NiJr6 GRNBEWQd2xaShSwUl3xk/zh/m; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:38557 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1boY8P-0000HJ-3r; Mon, 26 Sep 2016 09:48:01 -0600 To: Ruediger.Geib@telekom.de, rtg-ads@ietf.org References: <0d94e2cd77f34749b688fd4f8e3e7f8e@HE101653.emea1.cds.t-internal.com> From: Lou Berger Message-ID: <6f2b1611-b08d-3aa9-106e-025d6ebc72a5@labn.net> Date: Mon, 26 Sep 2016 11:47:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <0d94e2cd77f34749b688fd4f8e3e7f8e@HE101653.emea1.cds.t-internal.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1boY8P-0000HJ-3r X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:38557 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-tsvwg-diffserv-intercon.all@ietf.org, tsvwg@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 15:48:10 -0000 Hi Ruediger, Thanks for the response -- see below. On 9/20/2016 10:19 AM, Ruediger.Geib@telekom.de wrote: > Hi Lou, > > thanks for your review and feedback. My response took a few days (I tried to coordinate with David, but failed to reach him). > > I will change the document in several parts trying to follow your guidance. I'd like to discuss your comment related to section 2. > > The Introduction mentions Short-Pipe and says Diffserv-intercon is useful for it. I don't think the latter introduces MPLS Short Pipe to a reader if it isn't operational in his own network. One of the implications of MPLS Short Pipe for non tunneled IP is rewrite DSCP unknown to zero at the network Ingress. Non-tunneled is distinguished from tunneled IP (could be an IP-tunnel, could be IP traffic routed via an IP over MPLS VPN). > Should we add an explanation of "non-tunneled IP"? Perhaps this would help. > MPLS Short Pipe use according to RFC3270 and here for the non-tunneled IP traffic is as follows, I think (X, Y, Z indicate DiffServ Domains, IR and ER Ingress Router and Egress Router, PLSR Pen-ultimate LSR): > > X - [IR] - Y - [PLSR] - Y Forwarding, X DSCP - [ER] - X > - Y Forwarding, Y DSCP - [ER] - Y > > Capitol letter alone: Forwarding and MPLS TC/DSCP respectively of that domain. > > Diffserv-Intercon is close to that. Let's add Diffserv-intercon's D DSCP and assume that each domain operates the Diffserv-intercon PHBs by an own domain flavour: > > X Forwarding, D DSCP - [IR] - Y - [ER] - Y Forwarding, D DSCP > - Y - [ER] - Y > > Replace "D DSCP" by "X DSCP" -> a similarity with RFC3270 as originally designed is visible. > > Taking each line of the example as an option for a realization, both cases are possible and interoperable in the Diffserv-intercon case. > > I thought, a separate section is useful to indicate why there's a rewrite of the incoming DSCP for non-tunneled IP at the ingress. Deutsche Telekom doesn't support the first line showing Short Pipe as specified by RFC3270. The LERs do not handle traffic with DSCPs of downstream networks. Diffserv-intercon offers a kind of replacement here. Perhaps the intent will be more clear once you revise as you were suggesting above. Thanks, Lou > Regards, Ruediger > > -----Message----- > From: Lou Berger [mailto:lberger@labn.net] > mailed: Samstag, 10. September 2016 21:00 > To: rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-tsvwg-diffserv-intercon.all@ietf.org; tsvwg > Subject: RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 > > [snip] > > Minor Issues: > > [snip] > > - Intent of section 2 > > I found the purpose of Section 2 entirely unclear. This may have been due to some of the confusing text it contains (e.g., the 3rd sentence of the Section - what is non-tunneled IP traffic in an MPLS network, and why would an MPLS provider be tunneling traffic in IP tunnels?) > > If it's merely to introduce MPLS Short Pipe's and PHP, then this is accomplished in section 1 -- and by RFC3270 itself. If this is the sole purpose, than perhaps it would be easiest/best to just delete the section or combine it with Appendix A. If there is another purpose that is core to the document, I think the text needs to be revised to make that purpose clear, > > [snip] > From nobody Mon Sep 26 09:00:03 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A41412B2CB; Mon, 26 Sep 2016 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYdrl8Emv7BT; Mon, 26 Sep 2016 09:00:00 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCC312B24C; Mon, 26 Sep 2016 09:00:00 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id r126so211989500oib.0; Mon, 26 Sep 2016 09:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gh9dimIJ+QS7XgZYvnHVGo8OzFloE5cu2UmFMGyUFv8=; b=PKznevnwgpG4qaDu6kWHySA7/Brt4ID5Tlk6jpFPyiizq9NHTIqJJviwLsnAEvLaX6 rlE4H9hclh7xO7ygN8oCTFUA+mTHlyNIn01uWrxdUs1xQlckIayjzoxxuhANm7vcZk3b SvismjjRZPjn4hiI2GvogfiyL4/+hpUoXkisoVHodPiUi8Qwm0lhE347A1rPLJL1m3o2 rJxaUwgvCi1uqNDTvDXOwSu7ewou9rSDoPeno644zUHD0iwLIIQGVEiBbUh85iYTYOhM doWTmLrMylaYvy1xZ0mE2+3FrOxCcY6If8/mU9z8oGzfN9cC8Co8VZiGNGw/1TF9jbI6 pjZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gh9dimIJ+QS7XgZYvnHVGo8OzFloE5cu2UmFMGyUFv8=; b=dcS5f3viDGNTZJ1lEmoSQtCtT/TU1tBkIbruHg9R8Rr6kM7ag7x8UY7IWC2TUxIipf gUZuAFwQ7MLsodSVfxsLFtDV6BN35Uc6OGfVSInch1p6XNGqDFiS/Cxn8U1BPb34QS6b sKKa00YnE8cEBRo6kxV5W+ppIMKpyiXT2XzoH4Yqh21/BT+eeDqkWEO4AnsFmb/dVy4J I+yAvd5DkhF1ZFb9JWE4ihr6/J7hJgiVpSV34TFhc1k02TY0bCdgQUoZ0PGBg1ZtLPCJ 8T5G3JWLnvYOhGc/c/uVMAUYO33kGGVbwv6CNmkhW2V8QDY1Pxq11JgO8j/r+WHTmE8R zDFA== X-Gm-Message-State: AE9vXwN+Ra2KJRWizSilXkaq710aWPKSJf3iZcqt2+g5Mr1cULwCplZoZ4fcmUkfm/XcCRgyxyWBn6csxqd5YQ== X-Received: by 10.202.84.67 with SMTP id i64mr28127964oib.100.1474905599871; Mon, 26 Sep 2016 08:59:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.166.97 with HTTP; Mon, 26 Sep 2016 08:59:39 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 26 Sep 2016 11:59:39 -0400 Message-ID: To: John E Drake Content-Type: multipart/alternative; boundary=001a113d2ac65b9090053d6b38b4 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pals-endpoint-fast-protection.all@ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-endpoint-fast-protection-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 16:00:02 -0000 --001a113d2ac65b9090053d6b38b4 Content-Type: text/plain; charset=UTF-8 John, Thanks for your review! Cheers, Andy On Mon, Sep 26, 2016 at 11:22 AM, John E Drake 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-pals-endpoint-fast-protection-03 > Reviewer: John Drake > Review Date: 09/23/2016 > IETF LC End Date: > Intended Status: Standards Track > > Summary: > > No issues found. This document is ready for publication. > > Comments: > > Major Issues: > > None > > Minor > > None > > Nits: > > None > > Yours Irrespectively, > > John > > --001a113d2ac65b9090053d6b38b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

Thanks for your review!

Cheers,
Andy

On Mon, Sep 26, 2016 at 11:22 AM, John E D= rake <jdrake@juniper.net> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing 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 wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.

Document: draft-ietf-pals-endpoint-fast-protection-03
Reviewer: John Drake
Review Date: 09/23/2016
IETF LC End Date:
Intended Status: Standards Track

Summary:

No issues found. This document is ready for publication.

Comments:

Major Issues:

None

Minor

None

Nits:

None

Yours Irrespectively,

John


--001a113d2ac65b9090053d6b38b4-- From nobody Mon Sep 26 09:05:19 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C16112B2CB; Mon, 26 Sep 2016 09:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qni9ZHDchmFs; Mon, 26 Sep 2016 09:05:14 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0094.outbound.protection.outlook.com [104.47.32.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3E612B2BE; Mon, 26 Sep 2016 09:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=f61xhZiUqzDYi2AcACpgH1YuKI9JWnP6s1fTBSh1uoQ=; b=B2gRD4JW4Rt0i2DHJ8mqmY7gtPJk9tAQ7LOWZXdWQgzz947t12faTN/wl/bbWyxWCKh/68VuznY5h79umCuRbnVyUx9X0jdxuhr4ihcQpc3+wF5L+bwdl2zaRdKsGH4Bql6IZYfDoF1Xkg2PQ0a9ZoLvWeRYxl2kq/vDP0fwvPA= Received: from BN3PR0501MB1554.namprd05.prod.outlook.com (10.161.217.144) by BN6PR05MB2993.namprd05.prod.outlook.com (10.173.19.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.6; Mon, 26 Sep 2016 16:05:13 +0000 Received: from BN3PR0501MB1554.namprd05.prod.outlook.com ([10.161.217.144]) by BN3PR0501MB1554.namprd05.prod.outlook.com ([10.161.217.144]) with mapi id 15.01.0649.013; Mon, 26 Sep 2016 16:05:13 +0000 From: Yimin Shen To: "Andrew G. Malis" , John E Drake Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pals-endpoint-fast-protection-03 Thread-Index: AdIYCVtHojkMCz2DTHefc9cPDZY6sQABaEaA//++fgA= Date: Mon, 26 Sep 2016 16:05:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 authentication-results: spf=none (sender IP is ) smtp.mailfrom=yshen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: be6c0242-0afc-46c1-f883-08d3e626e602 x-microsoft-exchange-diagnostics: 1; BN6PR05MB2993; 7:u6H6xfQY7qjBZORNB62dV9d1pmJAnvNYRV1DRq00XvJdiJ0VP9p6FKw9j72d67lJcgDzXkZGpUHuKq2fN17NhbmNFN5V8r0GJniWvIdLW3zbX3+DB3nbLo7ZLn6u4P7HHu4ArRNn2tqX2ZBaaP4nZQgCU42hKkxPAGkceJukGwHr1Z+63rbFFVd0iq2CjgQJW+GofRkng8Ps3T1WTTx4xA5iAEZCHLtiev9xRXuF3bW7P+wYnEsoaAk5I2mIFE1ub2YMr/QirgAONZnLtpiADD1hJ+ongq5MTB10G3EwJlvOYvzVoeGd6WxAYNRxHXzJRjn3avqTMOtUB4oeb29PLw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR05MB2993; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(138986009662008)(97927398514766)(95692535739014)(21748063052155)(201166117486090)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BN6PR05MB2993; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB2993; x-forefront-prvs: 00770C4423 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(24454002)(199003)(2950100002)(19580405001)(19580395003)(76176999)(16236675004)(101416001)(19625215002)(33656002)(3660700001)(2900100001)(77096005)(3280700002)(54356999)(19300405004)(11100500001)(10400500002)(86362001)(15975445007)(68736007)(36756003)(5001770100001)(83506001)(6116002)(189998001)(102836003)(3846002)(1941001)(50986999)(97736004)(105586002)(83716003)(7736002)(230783001)(7846002)(19617315012)(5660300001)(2906002)(8676002)(81156014)(81166006)(8936002)(7906003)(4326007)(122556002)(5002640100001)(6862003)(66066001)(92566002)(99286002)(106356001)(586003)(87936001)(4001350100001)(82746002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB2993; H:BN3PR0501MB1554.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E6A3D253D1924CDAA6E5ADB184702819junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2016 16:05:13.0551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2993 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-pals-endpoint-fast-protection.all@ietf.org" , "pals@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-endpoint-fast-protection-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 16:05:17 -0000 --_000_E6A3D253D1924CDAA6E5ADB184702819junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEpvaG4sDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3ICENCg0KVGhhbmtz LA0KDQotLSBZaW1pbiBTaGVuDQoNCg0KRnJvbTogIkFuZHJldyBHLiBNYWxpcyIgPGFnbWFsaXNA Z21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTYgYXQgMTE6NTkgQU0N ClRvOiBKb2huIEUgRHJha2UgPGpkcmFrZUBqdW5pcGVyLm5ldD4NCkNjOiAicnRnLWFkc0BpZXRm Lm9yZyIgPHJ0Zy1hZHNAaWV0Zi5vcmc+LCAicnRnLWRpckBpZXRmLm9yZyIgPHJ0Zy1kaXJAaWV0 Zi5vcmc+LCAicGFsc0BpZXRmLm9yZyIgPHBhbHNAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1wYWxz LWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXBhbHMt ZW5kcG9pbnQtZmFzdC1wcm90ZWN0aW9uLmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUlRH LURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1wYWxzLWVuZHBvaW50LWZhc3QtcHJvdGVj dGlvbi0wMw0KUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KUmVzZW50LVRv OiBZaW1pbiBTaGVuIDx5c2hlbkBqdW5pcGVyLm5ldD4sIDxyYWdnYXJ3YV8xQHlhaG9vLmNvbT4s IDx3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5iZT4sIDxqaWFuZ3l1YW5sb25nQGh1YXdl aS5jb20+LCA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tPiwgPGFnbWFsaXNAZ21haWwuY29tPiwg PGRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20+LCA8YXJldGFuYUBjaXNjby5jb20+LCA8ZGIz NTQ2QGF0dC5jb20+LCA8YWthdGxhc0BnbWFpbC5jb20+LCBTdGV3YXJ0IEJyeWFudCA8c3Rld2Fy dC5icnlhbnRAZ21haWwuY29tPg0KUmVzZW50LURhdGU6IE1vbmRheSwgU2VwdGVtYmVyIDI2LCAy MDE2IGF0IDEyOjAwIFBNDQoNCkpvaG4sDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXchDQoNCkNo ZWVycywNCkFuZHkNCg0KT24gTW9uLCBTZXAgMjYsIDIwMTYgYXQgMTE6MjIgQU0sIEpvaG4gRSBE cmFrZSA8amRyYWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJha2VAanVuaXBlci5uZXQ+PiB3cm90 ZToNCkhlbGxvLA0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3Rv cmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vl a3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhl eSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRp bWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBw cm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSBodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyDQoNCkFsdGhvdWdoIHRoZXNl IGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBp dCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGgg YW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBz dHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0 aGUgZHJhZnQuDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbHMtZW5kcG9pbnQtZmFzdC1wcm90 ZWN0aW9uLTAzDQpSZXZpZXdlcjogSm9obiBEcmFrZQ0KUmV2aWV3IERhdGU6IDA5LzIzLzIwMTYN CklFVEYgTEMgRW5kIERhdGU6DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KDQpT dW1tYXJ5Og0KDQpObyBpc3N1ZXMgZm91bmQuIFRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1 YmxpY2F0aW9uLg0KDQpDb21tZW50czoNCg0KTWFqb3IgSXNzdWVzOg0KDQpOb25lDQoNCk1pbm9y DQoNCk5vbmUNCg0KTml0czoNCg0KTm9uZQ0KDQpZb3VycyBJcnJlc3BlY3RpdmVseSwNCg0KSm9o bg0KDQo= --_000_E6A3D253D1924CDAA6E5ADB184702819junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSwgSm9obiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5UaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldyAhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6YmxhY2siPi0tIFlpbWluIFNoZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mcXVvdDtBbmRyZXcgRy4g TWFsaXMmcXVvdDsgJmx0O2FnbWFsaXNAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5N b25kYXksIFNlcHRlbWJlciAyNiwgMjAxNiBhdCAxMTo1OSBBTTxicj4NCjxiPlRvOiA8L2I+Sm9o biBFIERyYWtlICZsdDtqZHJha2VAanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDtydGctYWRzQGlldGYub3JnJnF1b3Q7ICZsdDtydGctYWRzQGlldGYub3JnJmd0OywgJnF1b3Q7 cnRnLWRpckBpZXRmLm9yZyZxdW90OyAmbHQ7cnRnLWRpckBpZXRmLm9yZyZndDssICZxdW90O3Bh bHNAaWV0Zi5vcmcmcXVvdDsgJmx0O3BhbHNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRm LXBhbHMtZW5kcG9pbnQtZmFzdC1wcm90ZWN0aW9uLmFsbEBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJh ZnQtaWV0Zi1wYWxzLWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi5hbGxAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbUlRHLURJUl0gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0 Zi1wYWxzLWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi0wMzxicj4NCjxiPlJlc2VudC1Gcm9tOiA8 L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+ WWltaW4gU2hlbiAmbHQ7eXNoZW5AanVuaXBlci5uZXQmZ3Q7LCAmbHQ7cmFnZ2Fyd2FfMUB5YWhv by5jb20mZ3Q7LCAmbHQ7d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuYmUmZ3Q7LCAmbHQ7 amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tJmd0OywgJmx0O3N0ZXdhcnQuYnJ5YW50QGdtYWlsLmNv bSZndDssICZsdDthZ21hbGlzQGdtYWlsLmNvbSZndDssICZsdDtkYXZpZC5zaW5pY3JvcGVAZXJp Y3Nzb24uY29tJmd0OywgJmx0O2FyZXRhbmFAY2lzY28uY29tJmd0OywgJmx0O2RiMzU0NkBhdHQu Y29tJmd0OywNCiAmbHQ7YWthdGxhc0BnbWFpbC5jb20mZ3Q7LCBTdGV3YXJ0IEJyeWFudCAmbHQ7 c3Rld2FydC5icnlhbnRAZ21haWwuY29tJmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+TW9u ZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTYgYXQgMTI6MDAgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9o biwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Mg Zm9yIHlvdXIgcmV2aWV3ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgU2VwIDI2LCAyMDE2IGF0IDExOjIyIEFNLCBKb2hu IEUgRHJha2UgJmx0OzxhIGhyZWY9Im1haWx0bzpqZHJha2VAanVuaXBlci5uZXQiIHRhcmdldD0i X2JsYW5rIj5qZHJha2VAanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPkhlbGxvLDxicj4NCjxicj4NCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0 aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJl Y3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRy YWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcs IGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUNCiBy ZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1v cmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUN CjxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9S dGdEaXIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0 Zy90cmFjL3dpa2kvUnRnRGlyPC9hPjxicj4NCjxicj4NCkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRz IGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBi ZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVy IElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8g cmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQu PGJyPg0KPGJyPg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFscy1lbmRwb2ludC1mYXN0LXByb3Rl Y3Rpb24tMDM8YnI+DQpSZXZpZXdlcjogSm9obiBEcmFrZTxicj4NClJldmlldyBEYXRlOiAwOS8y My8yMDE2PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTo8YnI+DQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5k YXJkcyBUcmFjazxicj4NCjxicj4NClN1bW1hcnk6PGJyPg0KPGJyPg0KTm8gaXNzdWVzIGZvdW5k LiBUaGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi48YnI+DQo8YnI+DQpDb21t ZW50czo8YnI+DQo8YnI+DQpNYWpvciBJc3N1ZXM6PGJyPg0KPGJyPg0KTm9uZTxicj4NCjxicj4N Ck1pbm9yPGJyPg0KPGJyPg0KTm9uZTxicj4NCjxicj4NCk5pdHM6PGJyPg0KPGJyPg0KTm9uZTxi cj4NCjxicj4NCllvdXJzIElycmVzcGVjdGl2ZWx5LDxicj4NCjxicj4NCkpvaG48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E6A3D253D1924CDAA6E5ADB184702819junipernet_-- From nobody Mon Sep 26 09:06:57 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B394012B313 for ; Mon, 26 Sep 2016 09:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 mmBYGH2EKENF for ; Mon, 26 Sep 2016 09:06:53 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 78F1B12B31E for ; Mon, 26 Sep 2016 09:06:21 -0700 (PDT) Received: (qmail 15237 invoked by uid 0); 26 Sep 2016 16:06:19 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 26 Sep 2016 16:06:19 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id oG6E1t00b2SSUrH01G6HdY; Mon, 26 Sep 2016 10:06:17 -0600 X-Authority-Analysis: v=2.1 cv=F4vEKMRN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=GW1xBdLrtEIA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=h-9hJ6z7xL8EUHLFWAsA:9 a=hvIyfLTKsTjvWR0T:21 a=du0V_MR2WVjgBysT:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=z8j9LLIDd/ngghgWzS2+s0D7PwPkegxFLvXaXs4hcnw=; b=u1KOK2vIocY1pvap12PEB4Kzqn 5/yhYF1RiPSam9suOhqTo11fgguBJH5/YUyBtVQGE3/T+8NQkID8oLfQn4KlgjrVFqa/XIUccfcYN duBnaqoo2Ihj8KylyAnQZazXl; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:38382 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1boYQ4-0003aI-BF; Mon, 26 Sep 2016 10:06:16 -0600 To: "Black, David" , "rtg-ads@ietf.org" References: From: Lou Berger Message-ID: Date: Mon, 26 Sep 2016 12:06:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1boYQ4-0003aI-BF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:38382 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-tsvwg-diffserv-intercon.all@ietf.org" , tsvwg Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 16:06:56 -0000 Hi David, Thanks for the response -- see below... On 9/20/2016 10:14 PM, Black, David wrote: > Lou, > > [Commenting as a draft author, not WG chair] > > Thanks for the review, and sorry for the delayed response - EMC is now part > of Dell, and my life's been "interesting" as a result ... > > Ruediger's commented on your Section 2 concern, so I'll pick up the other > two minor issues, and add some more commentary on Section 2 ... > >> - The first issue is target use / applicability >> >> The document title implies that the document scope may apply to any >> provider interconnection as does 1st sentence of the 3rd paragraph 3 of >> section 1; IP tunnels are also mentioned in Section 4.3. Yet the >> Abstract and Section 1.2 state applicability is to MPLS-based providers. > Applicability is to any provider interconnection, with suitability for > MPLS-based providers being a significant design goal/rationale, due to > the limited number of bits/values available for Diffserv in an MPLS label. Okay - so it's any type of provider and motivated/constrained by providers that use MPLS Short-Pipe tunnels. Right? If yes, the Abstract/intro/etc should be revised to be consistent with this. > >> Section 4 then further narrows applicability 4 classes of traffic. > That definitely needs editing attention, as the 4 aggregated classes > of traffic are the core of the design - almost any network traffic can > be carried via an interconnection using the structure described in this > draft. "any" is a pretty broad statement. I wouldn't argue with "almost any DiffServ traffic". > All of the traffic classes defined in RFC 4594 have been > covered in the specification of the aggregates. > >> - Use of 'QoS' >> >> I find QoS undefined in the document and is really being used >> synonymously with 'traffic class', 'traffic treatment', 'DSCP', 'Class >> of Service' and even DiffServ itself in the document. I think the >> intent and clarity of the document would be improved by removing or >> replacing all instances of QoS. This would obviate needing to define >> what QoS means in the context of the specific (and limited) usage of >> DiffServ, as well as avoid naming consistency with other documents. > Ok, we'll at least greatly reduce use of "QoS" or eliminate it entirely. Elimination would be great. > >> - Intent of section 2 >> >> I found the purpose of Section 2 entirely unclear. > [... snip ...] > >> If it's merely to introduce MPLS Short Pipe's and PHP, then this is >> accomplished in section 1 -- and by RFC3270 itself. > Nope, Section 2's purpose is to outline the constraints on the design > space that lead to what we did. Diffserv tunneling is described in > RFC 2983, where the tunnel header is removed at the tunnel egress, > so two DSCP values are available to the tunnel egress node. MPLS > short pipe's use of PHP (as described in RFC 3270) departs from RFC 2983 > with the result that only one usable DSCP value is available to the tunnel > egress node. Explaining that and the resulting design restrictions > is the primary purpose of Section 2, see the last paragraph in that > section > - this is needed to make the draft accessible to those who > aren't MPLS experts. Then perhaps add a statement to this effect, e.g., something along the lines of "This section provides a summary of the implications of using the MPLS short pipe's use of PHP (as described in RFC 3270) on RFC 2983." Or what ever phrase you want to make it clear that this section is simply background information and not trying to define anything new to be considered. > Along the way, it was also necessary to dismiss RFC 2474's > recommendation to "forward traffic with unrecognized DSCPs > with Default (best effort) service without rewriting the DSCP" humm, so you are trying to deprecate/change the RFC2119 language of a standards track document in an informational document? Seems like a bit of odd way to accomplish an update. Is this really the goal? Thanks, Lou > as poor operational practice and focus on traffic that does not > use a provider-provisioned IP tunnel across the provider's > network. These constraints plus MPLS short-pipe PHP > severely limit the design space. > > Thanks, --David > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Saturday, September 10, 2016 3:00 PM >> To: rtg-ads@ietf.org >> Cc: rtg-dir@ietf.org; draft-ietf-tsvwg-diffserv-intercon.all@ietf.org; tsvwg >> Subject: RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 >> >> 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-tsvwg-diffserv-intercon-09 >> Reviewer: Lou Berger >> Review Date: Sept 10 >> Intended Status: Informational >> >> Summary: >> >> I have some minor concerns about this document that I think should >> be resolved before publication. >> >> Comments: >> >> This document is being published as Informational as such my review and >> comments focus more on the clarity of the document than its specific >> recommendations. While the document has no major issues, I think the >> currently has a number of confusing, if not contradictory, statements >> that should be clarified prior to publications. There are also a number >> of other issues, ranging from minor to nit - level, that should also be >> addressed. >> >> >> Major Issues: >> >> No major issues found. >> >> Minor Issues: >> >> - The first issue is target use / applicability >> >> The document title implies that the document scope may apply to any >> provider interconnection as does 1st sentence of the 3rd paragraph 3 of >> section 1; IP tunnels are also mentioned in Section 4.3. Yet the >> Abstract and Section 1.2 state applicability is to MPLS-based providers. >> Section 4 then further narrows applicability 4 classes of traffic. >> >> I think the applicability of this document to both (a) intra-provider >> technologies and (b) supported traffic classes need to be clarified and >> consistent across the document's Title, Abstract, Intro/Applicability >> and other sections. >> >> - Use of 'QoS' >> >> I find QoS undefined in the document and is really being used >> synonymously with 'traffic class', 'traffic treatment', 'DSCP', 'Class >> of Service' and even DiffServ itself in the document. I think the >> intent and clarity of the document would be improved by removing or >> replacing all instances of QoS. This would obviate needing to define >> what QoS means in the context of the specific (and limited) usage of >> DiffServ, as well as avoid naming consistency with other documents. >> >> - Intent of section 2 >> >> I found the purpose of Section 2 entirely unclear. This may have been >> due to some of the confusing text it contains (e.g., the 3rd sentence >> of the Section - what is non-tunneled IP traffic in an MPLS network, and >> why would an MPLS provider be tunneling traffic in IP tunnels?) >> >> If it's merely to introduce MPLS Short Pipe's and PHP, then this is >> accomplished in section 1 -- and by RFC3270 itself. If this is the sole >> purpose, than perhaps it would be easiest/best to just delete the >> section or combine it with Appendix A. If there is another purpose that >> is core to the document, I think the text needs to be revised to make >> that purpose clear, >> >> >> Nits: >> >> - The document is inconsistent in how it references RFCs. At times, it >> expands the RFC as text (e.g., "RFC 2475") other times it uses reference >> notation (e.g., [RFC5127]) other times it uses both (e.g, RFC 5127 >> [RFC5127]). Some consistency on use / intent would benefit the document. >> >> From nobody Mon Sep 26 12:44:19 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4D12B00E; Mon, 26 Sep 2016 12:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=NWv1skv6; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=uKCPYXg/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy51Np-scYHH; Mon, 26 Sep 2016 12:44:15 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 8CFF612B26E; Mon, 26 Sep 2016 12:44:15 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Cc:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=I82aINXnEP2NJhd2dp5TE9ujCQqLCM/BRYJfXGYceKzzyI5Bz8cRStaI mFalXhpAMEVZ5OlCRsfgjx+U5Y2pHkZ47whvfbTBXjDoFn55e/RVPan+R z8PH49+CBaHpFwqsn0wS9/PEIpuh2mfZYbACsvgaJdrLoXtMVihiS4yVm o=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1474919055; x=1506455055; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Kg9Ux+t4teJuaMed+x+HgjRe3vZ3PHwMaz8cH6ii/4k=; b=NWv1skv6r752R4lEOU4TQwRAKlIHsskaiUtewvOnTd8OgyO6Yqr0/1OE Ef/XD3hoh1AXPhnikuroMlQ9zTYmLW19LtdEuxXu6HtNZmBlKtOP7E8pm HCP50HwqwImCJ3FkeTR/zpX25mujc9Iv64WIrZL9YPNcwWZ1JTssMPfNH U=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2016 14:44:14 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2016 01:44:13 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8QJiBQn014155 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Sep 2016 15:44:12 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u8QJiBQn014155 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1474919052; bh=nB86Miut+D6zR4ibpzx2/4Fz6Vw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=uKCPYXg/ilsCuazJfIYTgwomXVa/LntLFP7syWOVM2nK9DK7a2dTuCD+goBAMULU2 qaQLNJyIPFYC0Nua79XiC6BDcfqnPKLjHNQ1+QPCrvfANzPEhssxkuk9RcTJhDM++8 v20GlcfTqxHMAtJKixkheY3ok8IbnDoaOhMEYlcs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u8QJiBQn014155 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd54.lss.emc.com (RSA Interceptor); Mon, 26 Sep 2016 15:43:56 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u8QJhuNt016572 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 26 Sep 2016 15:43:56 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0266.001; Mon, 26 Sep 2016 15:43:55 -0400 To: Lou Berger , "rtg-ads@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 Thread-Index: AQHSC5Z+EMftoXXCCkK62DPK7sfJpaCDOraggAkQ8wD//9vkgA== Date: Mon, 26 Sep 2016 19:43:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-tsvwg-diffserv-intercon.all@ietf.org" , tsvwg , "Black, David" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-diffserv-intercon-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:44:18 -0000 SGkgTG91LA0KDQpJIHRoaW5rIHdlJ3JlIG1vc3RseSBhbGlnbmVkLiAgVHdvIGZvbGxvdyB1cCBj b21tZW50cyBhcmUgYmVsb3csIGFuZA0KSSBjb25jdXIgd2l0aCB0aGUgcmVzdCBvZiB5b3VyIHJl bWFya3MuDQoNCi0gWzFdIC0NCj4gT2theSAtIHNvIGl0J3MgYW55IHR5cGUgb2YgcHJvdmlkZXIg YW5kIG1vdGl2YXRlZC9jb25zdHJhaW5lZCBieQ0KPiBwcm92aWRlcnMgdGhhdCB1c2UgTVBMUyBT aG9ydC1QaXBlIHR1bm5lbHMuICBSaWdodD8NCg0KWWVzLCByaWdodC4NCg0KPiBJZiB5ZXMsIHRo ZSBBYnN0cmFjdC9pbnRyby9ldGMgc2hvdWxkIGJlIHJldmlzZWQgdG8gYmUgY29uc2lzdGVudCB3 aXRoDQo+IHRoaXMuDQoNCldpbGwgZG8uDQoNCi0gWzJdIC0NCj4gPiBBbG9uZyB0aGUgd2F5LCBp dCB3YXMgYWxzbyBuZWNlc3NhcnkgdG8gZGlzbWlzcyBSRkMgMjQ3NCdzDQo+ID4gcmVjb21tZW5k YXRpb24gdG8gImZvcndhcmQgdHJhZmZpYyB3aXRoIHVucmVjb2duaXplZCBEU0NQcw0KPiA+IHdp dGggRGVmYXVsdCAoYmVzdCBlZmZvcnQpIHNlcnZpY2Ugd2l0aG91dCByZXdyaXRpbmcgdGhlIERT Q1AiDQo+IA0KPiBodW1tLCBzbyB5b3UgYXJlIHRyeWluZyB0byBkZXByZWNhdGUvY2hhbmdlIHRo ZSBSRkMyMTE5IGxhbmd1YWdlIG9mIGENCj4gc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50IGluIGFu IGluZm9ybWF0aW9uYWwgZG9jdW1lbnQ/ICBTZWVtcyBsaWtlIGEgYml0DQo+IG9mIG9kZCB3YXkg dG8gYWNjb21wbGlzaCBhbiB1cGRhdGUuICBJcyB0aGlzIHJlYWxseSB0aGUgZ29hbD8NCg0KTm9w ZSwgdGhlIG5leHQgd29yZHMgaW4gbXkgbm90ZSBhZnRlciB0aGUgYWJvdmUgUkZDIDI0NzQgcXVv dGUgd2VyZToNCg0KPiA+IGFzIHBvb3Igb3BlcmF0aW9uYWwgcHJhY3RpY2UNCg0KU28sIHRoZSBn b2FsIGlzIHRvIGNoYXJhY3Rlcml6ZSB0aGF0IFJGQyAyNDc0IHJlY29tbWVuZGF0aW9uIGFzIG5v dA0KcmVsZXZhbnQgaW4gcHJhY3RpY2UgdG8gdGhlIG5ldHdvcmsgb3BlcmF0b3IgaW50ZXJjb25u ZWN0IHNjZW5hcmlvcw0KZGlzY3Vzc2VkIGluIHRoaXMgZHJhZnQsIGFzIG5ldHdvcmsgb3BlcmF0 b3JzIGRvbid0IGRlcGxveSBEaWZmc2Vydg0KaW4gdGhhdCBmYXNoaW9uLg0KDQpBY3R1YWxseSBj aGFuZ2luZyBSRkMgMjQ3NCBpcyBub3QgYSBnb2FsIC0gdGhhdCB3b3VsZCBlbnRhaWwgYSBicm9h ZGVyLA0KcmF0aGVyIGRpZmZlcmVudCBzdGFuZGFyZHMtdHJhY2sgZHJhZnQgKGUuZy4sIHRoYXQg ZW5jb21wYXNzZXMgZGF0YQ0KY2VudGVyIGFuZCBlbnRlcnByaXNlIG5ldHdvcmsgRGlmZnNlcnYg dXNhZ2UsIHdoaWNoIGFyZSBvdXQgb2Ygc2NvcGUNCmZvciB0aGlzIGluZm9ybWF0aW9uYWwgZHJh ZnQpLCBhbmQgYXQgbGVhc3QgcmlnaHQgbm93LCBJJ20gbm90IGludGVyZXN0ZWQNCmluIG9wZW5p bmcgdGhhdCBjYW4gb2Ygd29ybXMgOy0pLg0KDQpSdWVkaWdlciBhbmQgSSB3aWxsIHdvcmsgdG9n ZXRoZXIgdG8gcmV2aXNlIHRoZSBkcmFmdCAtIHlvdXIgY29tbWVudHMNCmFyZSBkZWZpbml0ZWx5 IGFwcHJlY2lhdGVkLg0KDQpNYW55IFRoYW5rcywgLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0 XQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNiwgMjAxNiAxMjowNiBQTQ0KPiBUbzogQmxh Y2ssIERhdmlkOyBydGctYWRzQGlldGYub3JnDQo+IENjOiBydGctZGlyQGlldGYub3JnOyBkcmFm dC1pZXRmLXRzdndnLWRpZmZzZXJ2LWludGVyY29uLmFsbEBpZXRmLm9yZzsgdHN2d2cNCj4gU3Vi amVjdDogUmU6IFtSVEctRElSXSBSdGdEaXIgcmV2aWV3OiBkcmFmdC1pZXRmLXRzdndnLWRpZmZz ZXJ2LWludGVyY29uLTA5DQo+IA0KPiBIaSBEYXZpZCwNCj4gDQo+ICAgICBUaGFua3MgZm9yIHRo ZSByZXNwb25zZSAtLSBzZWUgYmVsb3cuLi4NCj4gDQo+IA0KPiBPbiA5LzIwLzIwMTYgMTA6MTQg UE0sIEJsYWNrLCBEYXZpZCB3cm90ZToNCj4gPiBMb3UsDQo+ID4NCj4gPiBbQ29tbWVudGluZyBh cyBhIGRyYWZ0IGF1dGhvciwgbm90IFdHIGNoYWlyXQ0KPiA+DQo+ID4gVGhhbmtzIGZvciB0aGUg cmV2aWV3LCBhbmQgc29ycnkgZm9yIHRoZSBkZWxheWVkIHJlc3BvbnNlICAtIEVNQyBpcyBub3cg cGFydA0KPiA+IG9mIERlbGwsIGFuZCBteSBsaWZlJ3MgYmVlbiAiaW50ZXJlc3RpbmciIGFzIGEg cmVzdWx0IC4uLg0KPiA+DQo+ID4gUnVlZGlnZXIncyBjb21tZW50ZWQgb24geW91ciBTZWN0aW9u IDIgY29uY2Vybiwgc28gSSdsbCBwaWNrIHVwIHRoZSBvdGhlcg0KPiA+IHR3byBtaW5vciBpc3N1 ZXMsIGFuZCBhZGQgc29tZSBtb3JlIGNvbW1lbnRhcnkgb24gU2VjdGlvbiAyIC4uLg0KPiA+DQo+ ID4+IC0gVGhlIGZpcnN0IGlzc3VlIGlzIHRhcmdldCB1c2UgLyBhcHBsaWNhYmlsaXR5DQo+ID4+ DQo+ID4+IFRoZSBkb2N1bWVudCB0aXRsZSBpbXBsaWVzIHRoYXQgdGhlIGRvY3VtZW50IHNjb3Bl IG1heSBhcHBseSB0byBhbnkNCj4gPj4gcHJvdmlkZXIgaW50ZXJjb25uZWN0aW9uIGFzIGRvZXMg MXN0IHNlbnRlbmNlIG9mIHRoZSAzcmQgcGFyYWdyYXBoIDMgb2YNCj4gPj4gc2VjdGlvbiAxOyBJ UCB0dW5uZWxzIGFyZSBhbHNvIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQuMy4gWWV0IHRoZQ0KPiA+ PiBBYnN0cmFjdCBhbmQgU2VjdGlvbiAxLjIgc3RhdGUgYXBwbGljYWJpbGl0eSBpcyB0byBNUExT LWJhc2VkIHByb3ZpZGVycy4NCj4gPiBBcHBsaWNhYmlsaXR5IGlzIHRvIGFueSBwcm92aWRlciBp bnRlcmNvbm5lY3Rpb24sIHdpdGggc3VpdGFiaWxpdHkgZm9yDQo+ID4gTVBMUy1iYXNlZCBwcm92 aWRlcnMgYmVpbmcgYSBzaWduaWZpY2FudCBkZXNpZ24gZ29hbC9yYXRpb25hbGUsIGR1ZSB0bw0K PiA+IHRoZSBsaW1pdGVkIG51bWJlciBvZiBiaXRzL3ZhbHVlcyBhdmFpbGFibGUgZm9yIERpZmZz ZXJ2IGluIGFuIE1QTFMgbGFiZWwuDQo+IA0KPiBPa2F5IC0gc28gaXQncyBhbnkgdHlwZSBvZiBw cm92aWRlciBhbmQgbW90aXZhdGVkL2NvbnN0cmFpbmVkIGJ5DQo+IHByb3ZpZGVycyB0aGF0IHVz ZSBNUExTIFNob3J0LVBpcGUgdHVubmVscy4gIFJpZ2h0Pw0KPiANCj4gSWYgeWVzLCB0aGUgQWJz dHJhY3QvaW50cm8vZXRjIHNob3VsZCBiZSByZXZpc2VkIHRvIGJlIGNvbnNpc3RlbnQgd2l0aA0K PiB0aGlzLg0KPiANCj4gPg0KPiA+PiAgU2VjdGlvbiA0IHRoZW4gZnVydGhlciBuYXJyb3dzIGFw cGxpY2FiaWxpdHkgNCBjbGFzc2VzIG9mIHRyYWZmaWMuDQo+ID4gVGhhdCBkZWZpbml0ZWx5IG5l ZWRzIGVkaXRpbmcgYXR0ZW50aW9uLCBhcyB0aGUgNCBhZ2dyZWdhdGVkIGNsYXNzZXMNCj4gPiBv ZiB0cmFmZmljIGFyZSB0aGUgY29yZSBvZiB0aGUgZGVzaWduIC0gYWxtb3N0IGFueSBuZXR3b3Jr IHRyYWZmaWMgY2FuDQo+ID4gYmUgY2FycmllZCB2aWEgYW4gaW50ZXJjb25uZWN0aW9uIHVzaW5n IHRoZSBzdHJ1Y3R1cmUgZGVzY3JpYmVkIGluIHRoaXMNCj4gPiBkcmFmdC4NCj4gImFueSIgaXMg YSBwcmV0dHkgYnJvYWQgc3RhdGVtZW50LiAgSSB3b3VsZG4ndCBhcmd1ZSB3aXRoICJhbG1vc3Qg YW55DQo+IERpZmZTZXJ2IHRyYWZmaWMiLg0KPiANCj4gPiAgQWxsIG9mIHRoZSB0cmFmZmljIGNs YXNzZXMgZGVmaW5lZCBpbiBSRkMgNDU5NCBoYXZlIGJlZW4NCj4gPiBjb3ZlcmVkIGluIHRoZSBz cGVjaWZpY2F0aW9uIG9mIHRoZSBhZ2dyZWdhdGVzLg0KPiA+DQo+ID4+IC0gVXNlIG9mICAnUW9T Jw0KPiA+Pg0KPiA+PiBJIGZpbmQgUW9TIHVuZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnQgYW5kIGlz IHJlYWxseSBiZWluZyB1c2VkDQo+ID4+IHN5bm9ueW1vdXNseSB3aXRoICd0cmFmZmljIGNsYXNz JywgJ3RyYWZmaWMgdHJlYXRtZW50JywgJ0RTQ1AnLCAnQ2xhc3MNCj4gPj4gb2YgU2VydmljZScg YW5kIGV2ZW4gRGlmZlNlcnYgaXRzZWxmIGluIHRoZSBkb2N1bWVudC4gIEkgdGhpbmsgdGhlDQo+ ID4+IGludGVudCBhbmQgY2xhcml0eSBvZiB0aGUgZG9jdW1lbnQgd291bGQgYmUgaW1wcm92ZWQg YnkgcmVtb3Zpbmcgb3INCj4gPj4gcmVwbGFjaW5nIGFsbCBpbnN0YW5jZXMgb2YgUW9TLiAgVGhp cyB3b3VsZCBvYnZpYXRlIG5lZWRpbmcgdG8gZGVmaW5lDQo+ID4+IHdoYXQgUW9TIG1lYW5zIGlu IHRoZSBjb250ZXh0IG9mIHRoZSBzcGVjaWZpYyAoYW5kIGxpbWl0ZWQpIHVzYWdlIG9mDQo+ID4+ IERpZmZTZXJ2LCBhcyB3ZWxsIGFzIGF2b2lkIG5hbWluZyBjb25zaXN0ZW5jeSB3aXRoIG90aGVy IGRvY3VtZW50cy4NCj4gPiBPaywgd2UnbGwgYXQgbGVhc3QgZ3JlYXRseSByZWR1Y2UgdXNlICBv ZiAiUW9TIiBvciBlbGltaW5hdGUgaXQgZW50aXJlbHkuDQo+IA0KPiBFbGltaW5hdGlvbiB3b3Vs ZCBiZSBncmVhdC4NCj4gDQo+ID4NCj4gPj4gLSBJbnRlbnQgb2Ygc2VjdGlvbiAyDQo+ID4+DQo+ ID4+IEkgZm91bmQgdGhlIHB1cnBvc2Ugb2YgU2VjdGlvbiAyIGVudGlyZWx5IHVuY2xlYXIuDQo+ ID4gWy4uLiBzbmlwIC4uLl0NCj4gPg0KPiA+PiBJZiBpdCdzIG1lcmVseSB0byBpbnRyb2R1Y2Ug TVBMUyBTaG9ydCBQaXBlJ3MgYW5kIFBIUCwgdGhlbiB0aGlzIGlzDQo+ID4+IGFjY29tcGxpc2hl ZCBpbiBzZWN0aW9uIDEgLS0gYW5kIGJ5IFJGQzMyNzAgaXRzZWxmLg0KPiA+IE5vcGUsIFNlY3Rp b24gMidzIHB1cnBvc2UgaXMgdG8gb3V0bGluZSB0aGUgY29uc3RyYWludHMgb24gdGhlIGRlc2ln bg0KPiA+IHNwYWNlIHRoYXQgbGVhZCB0byB3aGF0IHdlIGRpZC4gIERpZmZzZXJ2IHR1bm5lbGlu ZyBpcyBkZXNjcmliZWQgaW4NCj4gPiBSRkMgMjk4Mywgd2hlcmUgdGhlIHR1bm5lbCBoZWFkZXIg aXMgcmVtb3ZlZCBhdCB0aGUgdHVubmVsIGVncmVzcywNCj4gPiBzbyB0d28gRFNDUCB2YWx1ZXMg YXJlIGF2YWlsYWJsZSB0byB0aGUgdHVubmVsIGVncmVzcyBub2RlLiAgIE1QTFMNCj4gPiBzaG9y dCBwaXBlJ3MgdXNlIG9mIFBIUCAoYXMgZGVzY3JpYmVkIGluIFJGQyAzMjcwKSBkZXBhcnRzIGZy b20gUkZDIDI5ODMNCj4gPiB3aXRoIHRoZSByZXN1bHQgdGhhdCBvbmx5IG9uZSB1c2FibGUgRFND UCB2YWx1ZSBpcyBhdmFpbGFibGUgdG8gdGhlIHR1bm5lbA0KPiA+IGVncmVzcyBub2RlLiAgIEV4 cGxhaW5pbmcgdGhhdCBhbmQgdGhlIHJlc3VsdGluZyBkZXNpZ24gcmVzdHJpY3Rpb25zDQo+ID4g aXMgdGhlIHByaW1hcnkgcHVycG9zZSBvZiBTZWN0aW9uIDIsIHNlZSB0aGUgbGFzdCBwYXJhZ3Jh cGggaW4gdGhhdA0KPiA+IHNlY3Rpb24NCj4gDQo+ID4gLSB0aGlzIGlzIG5lZWRlZCB0byBtYWtl IHRoZSBkcmFmdCBhY2Nlc3NpYmxlIHRvIHRob3NlIHdobw0KPiA+IGFyZW4ndCBNUExTIGV4cGVy dHMuDQo+IA0KPiBUaGVuIHBlcmhhcHMgYWRkIGEgc3RhdGVtZW50IHRvIHRoaXMgZWZmZWN0LCBl LmcuLCBzb21ldGhpbmcgYWxvbmcgdGhlDQo+IGxpbmVzIG9mICJUaGlzIHNlY3Rpb24gcHJvdmlk ZXMgYSBzdW1tYXJ5IG9mIHRoZSBpbXBsaWNhdGlvbnMgb2YgdXNpbmcNCj4gdGhlIE1QTFMgc2hv cnQgcGlwZSdzIHVzZSBvZiBQSFAgKGFzIGRlc2NyaWJlZCBpbiBSRkMgMzI3MCkgb24gUkZDDQo+ IDI5ODMuIiAgIE9yIHdoYXQgZXZlciBwaHJhc2UgeW91IHdhbnQgdG8gbWFrZSBpdCBjbGVhciB0 aGF0IHRoaXMgc2VjdGlvbg0KPiBpcyBzaW1wbHkgYmFja2dyb3VuZCBpbmZvcm1hdGlvbiBhbmQg bm90IHRyeWluZyB0byBkZWZpbmUgYW55dGhpbmcgbmV3DQo+IHRvIGJlIGNvbnNpZGVyZWQuDQo+ IA0KPiA+IEFsb25nIHRoZSB3YXksIGl0IHdhcyBhbHNvIG5lY2Vzc2FyeSB0byBkaXNtaXNzIFJG QyAyNDc0J3MNCj4gPiByZWNvbW1lbmRhdGlvbiB0byAiZm9yd2FyZCB0cmFmZmljIHdpdGggdW5y ZWNvZ25pemVkIERTQ1BzDQo+ID4gd2l0aCBEZWZhdWx0IChiZXN0IGVmZm9ydCkgc2VydmljZSB3 aXRob3V0IHJld3JpdGluZyB0aGUgRFNDUCINCj4gDQo+IGh1bW0sIHNvIHlvdSBhcmUgdHJ5aW5n IHRvIGRlcHJlY2F0ZS9jaGFuZ2UgdGhlIFJGQzIxMTkgbGFuZ3VhZ2Ugb2YgYQ0KPiBzdGFuZGFy ZHMgdHJhY2sgZG9jdW1lbnQgaW4gYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudD8gIFNlZW1zIGxp a2UgYSBiaXQNCj4gb2Ygb2RkIHdheSB0byBhY2NvbXBsaXNoIGFuIHVwZGF0ZS4gIElzIHRoaXMg cmVhbGx5IHRoZSBnb2FsPw0KPiANCj4gVGhhbmtzLA0KPiBMb3UNCj4gDQo+ID4gYXMgcG9vciBv cGVyYXRpb25hbCBwcmFjdGljZSBhbmQgZm9jdXMgb24gdHJhZmZpYyB0aGF0IGRvZXMgbm90DQo+ ID4gdXNlIGEgcHJvdmlkZXItcHJvdmlzaW9uZWQgSVAgdHVubmVsIGFjcm9zcyB0aGUgcHJvdmlk ZXIncw0KPiA+IG5ldHdvcmsuICBUaGVzZSBjb25zdHJhaW50cyBwbHVzIE1QTFMgc2hvcnQtcGlw ZSBQSFANCj4gPiBzZXZlcmVseSBsaW1pdCB0aGUgZGVzaWduIHNwYWNlLg0KPiA+DQo+ID4gVGhh bmtzLCAtLURhdmlkDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g RnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+ID4+IFNlbnQ6IFNh dHVyZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTYgMzowMCBQTQ0KPiA+PiBUbzogcnRnLWFkc0BpZXRm Lm9yZw0KPiA+PiBDYzogcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi10c3Z3Zy1kaWZmc2Vy di1pbnRlcmNvbi5hbGxAaWV0Zi5vcmc7IHRzdndnDQo+ID4+IFN1YmplY3Q6IFJ0Z0RpciByZXZp ZXc6IGRyYWZ0LWlldGYtdHN2d2ctZGlmZnNlcnYtaW50ZXJjb24tMDkNCj4gPj4NCj4gPj4gSGVs bG8sDQo+ID4+DQo+ID4+IEkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVj dG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0KPiA+PiBUaGUgUm91dGluZyBEaXJlY3Rv cmF0ZSBzZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkDQo+ID4+ IGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZp ZXcsIGFuZA0KPiA+PiBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBv ZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUNCj4gPj4gYXNzaXN0YW5jZSB0byB0aGUgUm91dGlu ZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nDQo+ID4+IERpcmVj dG9yYXRlLCBwbGVhc2Ugc2VlDQo+ID4+IOKAi2h0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2Fy ZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCj4gPj4NCj4gPj4gQWx0aG91Z2ggdGhlc2UgY29tbWVu dHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0DQo+ID4+ IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURg0KPiA+PiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwg YW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaA0KPiA+PiBkaXNjdXNzaW9uIG9yIGJ5 IHVwZGF0aW5nIHRoZSBkcmFmdC4NCj4gPj4NCj4gPj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtdHN2 d2ctZGlmZnNlcnYtaW50ZXJjb24tMDkNCj4gPj4gUmV2aWV3ZXI6IExvdSBCZXJnZXINCj4gPj4g UmV2aWV3IERhdGU6IFNlcHQgMTANCj4gPj4gSW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1hdGlvbmFs DQo+ID4+DQo+ID4+IFN1bW1hcnk6DQo+ID4+DQo+ID4+ICAgICBJIGhhdmUgc29tZSBtaW5vciBj b25jZXJucyBhYm91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQNCj4gPj4gYmUg cmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiA+Pg0KPiA+PiBDb21tZW50czoNCj4gPj4N Cj4gPj4gVGhpcyBkb2N1bWVudCBpcyBiZWluZyBwdWJsaXNoZWQgYXMgSW5mb3JtYXRpb25hbCBh cyBzdWNoIG15IHJldmlldyBhbmQNCj4gPj4gY29tbWVudHMgZm9jdXMgbW9yZSBvbiB0aGUgY2xh cml0eSBvZiB0aGUgZG9jdW1lbnQgdGhhbiBpdHMgc3BlY2lmaWMNCj4gPj4gcmVjb21tZW5kYXRp b25zLiAgV2hpbGUgdGhlIGRvY3VtZW50IGhhcyBubyBtYWpvciBpc3N1ZXMsIEkgdGhpbmsgdGhl DQo+ID4+IGN1cnJlbnRseSBoYXMgYSBudW1iZXIgb2YgY29uZnVzaW5nLCBpZiBub3QgY29udHJh ZGljdG9yeSwgc3RhdGVtZW50cw0KPiA+PiB0aGF0IHNob3VsZCBiZSBjbGFyaWZpZWQgcHJpb3Ig dG8gcHVibGljYXRpb25zLiAgVGhlcmUgYXJlIGFsc28gYSBudW1iZXINCj4gPj4gb2Ygb3RoZXIg aXNzdWVzLCByYW5naW5nIGZyb20gbWlub3IgIHRvIG5pdCAtIGxldmVsLCB0aGF0IHNob3VsZCBh bHNvIGJlDQo+ID4+IGFkZHJlc3NlZC4NCj4gPj4NCj4gPj4NCj4gPj4gTWFqb3IgSXNzdWVzOg0K PiA+Pg0KPiA+PiAJTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KPiA+Pg0KPiA+PiBNaW5vciBJc3N1 ZXM6DQo+ID4+DQo+ID4+IC0gVGhlIGZpcnN0IGlzc3VlIGlzIHRhcmdldCB1c2UgLyBhcHBsaWNh YmlsaXR5DQo+ID4+DQo+ID4+IFRoZSBkb2N1bWVudCB0aXRsZSBpbXBsaWVzIHRoYXQgdGhlIGRv Y3VtZW50IHNjb3BlIG1heSBhcHBseSB0byBhbnkNCj4gPj4gcHJvdmlkZXIgaW50ZXJjb25uZWN0 aW9uIGFzIGRvZXMgMXN0IHNlbnRlbmNlIG9mIHRoZSAzcmQgcGFyYWdyYXBoIDMgb2YNCj4gPj4g c2VjdGlvbiAxOyBJUCB0dW5uZWxzIGFyZSBhbHNvIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQuMy4g WWV0IHRoZQ0KPiA+PiBBYnN0cmFjdCBhbmQgU2VjdGlvbiAxLjIgc3RhdGUgYXBwbGljYWJpbGl0 eSBpcyB0byBNUExTLWJhc2VkIHByb3ZpZGVycy4NCj4gPj4gIFNlY3Rpb24gNCB0aGVuIGZ1cnRo ZXIgbmFycm93cyBhcHBsaWNhYmlsaXR5IDQgY2xhc3NlcyBvZiB0cmFmZmljLg0KPiA+Pg0KPiA+ PiBJIHRoaW5rIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoaXMgZG9jdW1lbnQgdG8gYm90aCAoYSkg aW50cmEtcHJvdmlkZXINCj4gPj4gdGVjaG5vbG9naWVzIGFuZCAoYikgc3VwcG9ydGVkIHRyYWZm aWMgY2xhc3NlcyBuZWVkIHRvIGJlIGNsYXJpZmllZCBhbmQNCj4gPj4gY29uc2lzdGVudCBhY3Jv c3MgdGhlIGRvY3VtZW50J3MgVGl0bGUsIEFic3RyYWN0LCBJbnRyby9BcHBsaWNhYmlsaXR5DQo+ ID4+IGFuZCBvdGhlciBzZWN0aW9ucy4NCj4gPj4NCj4gPj4gLSBVc2Ugb2YgJ1FvUycNCj4gPj4N Cj4gPj4gSSBmaW5kIFFvUyB1bmRlZmluZWQgaW4gdGhlIGRvY3VtZW50IGFuZCBpcyByZWFsbHkg YmVpbmcgdXNlZA0KPiA+PiBzeW5vbnltb3VzbHkgd2l0aCAndHJhZmZpYyBjbGFzcycsICd0cmFm ZmljIHRyZWF0bWVudCcsICdEU0NQJywgJ0NsYXNzDQo+ID4+IG9mIFNlcnZpY2UnIGFuZCBldmVu IERpZmZTZXJ2IGl0c2VsZiBpbiB0aGUgZG9jdW1lbnQuICBJIHRoaW5rIHRoZQ0KPiA+PiBpbnRl bnQgYW5kIGNsYXJpdHkgb2YgdGhlIGRvY3VtZW50IHdvdWxkIGJlIGltcHJvdmVkIGJ5IHJlbW92 aW5nIG9yDQo+ID4+IHJlcGxhY2luZyBhbGwgaW5zdGFuY2VzIG9mIFFvUy4gIFRoaXMgd291bGQg b2J2aWF0ZSBuZWVkaW5nIHRvIGRlZmluZQ0KPiA+PiB3aGF0IFFvUyBtZWFucyBpbiB0aGUgY29u dGV4dCBvZiB0aGUgc3BlY2lmaWMgKGFuZCBsaW1pdGVkKSB1c2FnZSBvZg0KPiA+PiBEaWZmU2Vy diwgYXMgd2VsbCBhcyBhdm9pZCBuYW1pbmcgY29uc2lzdGVuY3kgd2l0aCBvdGhlciBkb2N1bWVu dHMuDQo+ID4+DQo+ID4+IC0gSW50ZW50IG9mIHNlY3Rpb24gMg0KPiA+Pg0KPiA+PiBJIGZvdW5k IHRoZSBwdXJwb3NlIG9mIFNlY3Rpb24gMiBlbnRpcmVseSB1bmNsZWFyLiAgVGhpcyBtYXkgaGF2 ZSBiZWVuDQo+ID4+IGR1ZSB0byBzb21lIG9mIHRoZSBjb25mdXNpbmcgdGV4dCBpdCBjb250YWlu cyAoZS5nLiwgIHRoZSAzcmQgc2VudGVuY2UNCj4gPj4gb2YgdGhlIFNlY3Rpb24gLSB3aGF0IGlz IG5vbi10dW5uZWxlZCBJUCB0cmFmZmljIGluIGFuIE1QTFMgbmV0d29yaywgYW5kDQo+ID4+IHdo eSB3b3VsZCBhbiBNUExTIHByb3ZpZGVyIGJlIHR1bm5lbGluZyB0cmFmZmljIGluIElQIHR1bm5l bHM/KQ0KPiA+Pg0KPiA+PiBJZiBpdCdzIG1lcmVseSB0byBpbnRyb2R1Y2UgTVBMUyBTaG9ydCBQ aXBlJ3MgYW5kIFBIUCwgdGhlbiB0aGlzIGlzDQo+ID4+IGFjY29tcGxpc2hlZCBpbiBzZWN0aW9u IDEgLS0gYW5kIGJ5IFJGQzMyNzAgaXRzZWxmLiAgSWYgdGhpcyBpcyB0aGUgc29sZQ0KPiA+PiBw dXJwb3NlLCB0aGFuIHBlcmhhcHMgaXQgd291bGQgYmUgZWFzaWVzdC9iZXN0IHRvIGp1c3QgZGVs ZXRlIHRoZQ0KPiA+PiBzZWN0aW9uIG9yIGNvbWJpbmUgaXQgd2l0aCBBcHBlbmRpeCBBLiAgSWYg dGhlcmUgaXMgYW5vdGhlciBwdXJwb3NlIHRoYXQNCj4gPj4gaXMgY29yZSB0byB0aGUgZG9jdW1l bnQsIEkgdGhpbmsgdGhlIHRleHQgbmVlZHMgdG8gYmUgcmV2aXNlZCB0byBtYWtlDQo+ID4+IHRo YXQgcHVycG9zZSBjbGVhciwNCj4gPj4NCj4gPj4NCj4gPj4gTml0czoNCj4gPj4NCj4gPj4gLSBU aGUgZG9jdW1lbnQgaXMgaW5jb25zaXN0ZW50IGluIGhvdyBpdCByZWZlcmVuY2VzIFJGQ3MuICBB dCB0aW1lcywgaXQNCj4gPj4gZXhwYW5kcyB0aGUgUkZDIGFzIHRleHQgKGUuZy4sICJSRkMgMjQ3 NSIpIG90aGVyIHRpbWVzIGl0IHVzZXMgcmVmZXJlbmNlDQo+ID4+IG5vdGF0aW9uIChlLmcuLCBb UkZDNTEyN10pIG90aGVyIHRpbWVzIGl0IHVzZXMgYm90aCAoZS5nLCBSRkMgNTEyNw0KPiA+PiBb UkZDNTEyN10pLiAgU29tZSBjb25zaXN0ZW5jeSBvbiB1c2UgLyBpbnRlbnQgd291bGQgYmVuZWZp dCB0aGUgZG9jdW1lbnQuDQo+ID4+DQo+ID4+DQoNCg== From nobody Tue Sep 27 02:01:12 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E2712B095; Tue, 27 Sep 2016 02:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq5ezHON8ih0; Tue, 27 Sep 2016 02:00:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 57D8912B09F; Tue, 27 Sep 2016 02:00:43 -0700 (PDT) X-AuditID: c1b4fb3a-aa3ff7000000099a-13-57ea353867d3 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 10.3F.02458.8353AE75; Tue, 27 Sep 2016 11:00:41 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Sep 2016 11:00:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QexV0Ab1ftNd/Eb8pe9fLN6Q/i9E62SCDfAixrYdTPo=; b=BMA3Dd4PrjDwELVoOC0N+N/fXuJKICDyCF+vfzmuTQb8HvRfeBFYvsnGHqws6mcWPPQSl6x5jsxBf8mwXqYuOumrkpwZITkdkIH6iPW33KdTTPy9eJnSGYH2wwB8d+DMUq4epr2ZSuoajDJoFhOEFt0s6qMaznACzDF0IzuU5pg= Received: from AM2PR07MB0994.eurprd07.prod.outlook.com (10.162.37.152) by AM2PR07MB0996.eurprd07.prod.outlook.com (10.162.37.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Tue, 27 Sep 2016 09:00:38 +0000 Received: from AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) by AM2PR07MB0994.eurprd07.prod.outlook.com ([10.162.37.152]) with mapi id 15.01.0639.011; Tue, 27 Sep 2016 09:00:38 +0000 From: Daniele Ceccarelli To: " (rtg-ads@ietf.org)" Thread-Topic: RtgDir review: draft-ietf-mpls-rfc4379bis-06 Thread-Index: AdIYlGctmue+loOwTiq6Dd9Tc8UYiA== Date: Tue, 27 Sep 2016 09:00:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [2.112.192.21] x-ms-office365-filtering-correlation-id: cb379418-d90f-4021-36f4-08d3e6b4c0a3 x-microsoft-exchange-diagnostics: 1; AM2PR07MB0996; 6:xAOC6jJrjpf/naCdxtpbywHXm3da9d6RTZT7+nzxdzLCjAZ74ygtp5b4UHNcISzbbR7aF1h6AJN1nNszIPK91SFPr0Ly/YTsvr7snX+7Sr92Kxa6GMfe0cgG+ckFfAs8AHadxwE2LxQembqk/wiHJkuSqSCFgKC1twZa2YUjHaGPromTy35zj3PPhj+QM2r3/pyppiWo9siI7NIS69fxqkHqhhLddQLplzVDu9UbAUHyDJiGNz4/LVokw+2mhnO9uyU81ItKbzGleGGUfgceIPZ7QfPSvFuqlM8loHU8IV4=; 5:c5YIS1/yMivxhR9I65xdaNranc+jTsNIB9BAbQlFf7gOYHt4unr7l7xE91P3pRNErdNA0KbslXu4n5BZnYuiGdoRDcnA8ydvCVbNcLxXX8/IHU8Ijz2InKQjMrGzh4XyYikVl7kOOqEBLM15cApXwA==; 24:rXnTwTjW3vAcPKumZGHyYkZHwWiT1aqclCItoYtLcc+0VKimJDr+nMX5boszsfTtNPNe2mOEtp2CfMLnFTOM94CEeZGKIU1nchEo9sgwxjQ=; 7:HrVD+VzAbcLJ0/XbCf3WwAL0QaFOZsuKHs9vCw5QgGdY9wQGK5vCcVRvKD2NqEnrgrEmPycaW6NyRVH1uLse8RsjHhPeT/KsgCIiOprz1r0McZfONHiGwbvTZHEsJ5aB3qVyJXWaK4dO4YjtBprJRKun7FzlZ1N8bc6YGouI/U+2EvRSPINWwRwalBkdMlc9krbS8nM0XLyG6OvAvVJvIZ4sCDPUnmPuVcLF/0SPndTlgnRtG9eq6wc/j+SMnnUBFXeYyzaHefGdvQGwrRKFdnvr/g0MTd3QMaafUDJff929pn5zx4FSb4hs6Aqpo4gw x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0996; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM2PR07MB0996; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0996; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(37854004)(199003)(189002)(16236675004)(3660700001)(101416001)(19580395003)(19300405004)(76576001)(105586002)(4326007)(106356001)(5002640100001)(87936001)(11100500001)(229853001)(66066001)(97736004)(5660300001)(189998001)(68736007)(10400500002)(19625215002)(3280700002)(7696004)(8936002)(15975445007)(74316002)(2900100001)(86362001)(110136003)(50986999)(54356999)(122556002)(2906002)(33656002)(77096005)(7846002)(790700001)(19617315012)(7906003)(102836003)(6116002)(3846002)(230783001)(81166006)(7736002)(81156014)(9686002)(8676002)(586003)(450100001)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0996; H:AM2PR07MB0994.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM2PR07MB09942196213D9DC0F539DABFF0CC0AM2PR07MB0994eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2016 09:00:38.8475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0996 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGe3fv3a6j4evSPKlBTiJT1CUZJuIHRBSaFUbrE115UVOn7Zql +IdBo3SUGtpwGCppftbSHA0/yC0cakFJBTI1PzJTG0gj0iVUXu8i//ud8zznvDyHlyak7ZQP nanKZ9QqZbZMKCZrzryIDjkYsaSQa98HRy4M4EhbUysVOVy7SkTWd3wRxZFHGhudghPonDg6 jcnOLGDUYTGp4oyJ76NU3rwD3dC9eUCWoG47KkNuNOD9MHmvmuRYig0IDG1Xy5B4nYcQDPYu kFxB4rsE3DGbCV6pEsBkZ5OAL6wINNM6qgzRtBBHwZwlkUNPHAP60RDOQuBHCEwNg0LuiW04 AvTGzg32XLebZ36KeA6FqbVnFMck3g3m5yUEt0eCL4DZ6cu1Ed4OKyMdAo4J7A22uToBnwBD Y99bgmcvWPz8m+L9l8CgMbk8u+BTl1XI8zFwasY3ggF+KgJn8zTFC4dhudLmOksWzAwNuYYT YEk3j/gBE4LSnlXXJj+wV3wT8sIPCoadJRR/SAaan2gQn9gHJj+UutgPFib6N45F4FywvC6q QHv0mwLp/ytcW4I9YLhmjuTbe8HQE8a7/aFKOyPiORA0tQ9Fm/v1SNSGvFiGZXPSw8NDGXXm ZZbNVYWqmPwutP6FzN1rUSZk/hpvQZhGsq2SVP2iQkopC9jCHAsCmpB5ShzyJYVUkqYsLGLU uSnqa9kMa0G+NCnzlhxonVJIcboyn8limDxG/U8V0G4+JSixt7vplXGHlcmrKR+/HnE/fqC6 Zeziy7mO/ir3U+KR8nHdrDWwOO5jckObNmfMQRYc2qJcTjau7HS8a0mVBxyXX/EYibHdlLMd lWN/FOfTc7SB7rH5/oOPY/NMfqO/7Kdng04W1zfYjV7B9tutRWcDko62pyTA2q2pedN4Ul2f jGQzlPuCCDWr/As58rtSPgMAAA== Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-rfc4379bis.all@ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-rfc4379bis-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 09:00:50 -0000 --_000_AM2PR07MB09942196213D9DC0F539DABFF0CC0AM2PR07MB0994eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcj4NCg0KQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbXBscy1yZmM0Mzc5YmlzLTA2DQpSZXZpZXdl cjogRGFuaWVsZSBDZWNjYXJlbGxpDQpSZXZpZXcgRGF0ZTogMjcvMDkvMjAxNg0KSUVURiBMQyBF bmQgRGF0ZTogZGF0ZS1pZi1rbm93bg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZCBUcmFjaw0K DQpXaGVuIEkgc2F3IHRoYXQgdGhlIGRvY3VtZW50IHdhcyBvYnNvbGV0aW5nIDQgd2VsbCBrbm93 biBhbmQgd2lkZWx5IGRlcGxveWVkIGRvY3VtZW50cyBJIHdhcyBzY2FyZWQsIGJ1dCByZWFkaW5n IHRoZSBzaGVwaGVyZCB3cml0ZSB1cCBpdCBzZWVtcyB0aGF0IHRoZSBkcmFmdHMgZ290IGEgd2lk ZSBjb25zZW5zdXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClN1bW1hcnk6DQpObyBpc3N1ZXMg Zm91bmQuIFRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLg0KDQpDb21tZW50 czoNCg0KVGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQgY29tcHJlaGVuc2libGUsIGJ1 dCBJIGRpZG7igJl0IGV4cGVjdCBsZXNzIGZyb20gc3VjaCBhIGRyZWFtIHRlYW0gb2YgYXV0aG9y cy4NCg0KTWFqb3IgSXNzdWVzOg0KDQogICogICAiTm8gbWFqb3IgaXNzdWVzIGZvdW5kLiINCg0K TWlub3IgSXNzdWVzOg0KDQogICogICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBJIHdvdWxkIGV4 cGVjdCB0byBzZWUgYSBzZWN0aW9uIHdpdGggc29tZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlz c3Vlcy4gUHJvYmFibHkgc2luY2UgYWxsIHRoZSBwcmV2aW91c2x5IGRlZmluZWQgbWV0aG9kcyBh bmQgZXh0ZW5zaW9ucyBhcmUgZGVwcmVjYXRlZCBubyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlz IGV4cGVjdGVkPyBJbiBhbnkgY2FzZSBpdCBpcyB3b3J0aCBtZW50aW9uaW5nIGl0Lg0KICAqICAg My4yLjguICBGRUMgMTI4IFBzZXVkb3dpcmUgLSBJUHY0IChEZXByZWNhdGVkKSB2cy4gMy4yLjku ICBGRUMgMTI4IFBzZXVkb3dpcmUgLSBJUHY0IChDdXJyZW50KS4gSSBkb27igJl0IHVuZGVyc3Rh bmQgdGhpcy4gSXMgdGhlcmUgYSBkZXByZWNhdGVkIHZlcnNpb24gb2YgdGhlIEZFQyAxMjggUFcg YW5kIGEgY3VycmVudCBvbmU/IFdoZXJlIGlzIHRoYXQgZGVwcmVjYXRlZD8gSSBkb27igJl0IHRo aW5rIHRoZXJlIGlzIHRoZSBuZWVkIHRvIGFkZHJlc3MgYm90aCBidXQganVzdCB0aGUgY3VycmVu dCBvbmUuDQoNCk5pdHM6DQoNCiAgKiAgIEkgdGhpbmsgdGhpcyBzZW50ZW5jZSBjYW4gYmUgcmVt b3ZlZCBmcm9tIHRoZSBBYnN0cmFjdCDigJxUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkNzIDQz NzksIDY0MjQsIDY4MjksIGFuZCA3NTM3LuKAnQ0KICAqICAgSW50cm9kdWN0aW9uOiAg4oCcQW4g aW1wb3J0YW50IGNvbnNpZGVyYXRpb24gaW4gdGhpcyBkZXNpZ24gaXMgdGhhdCBNUExTIGVjaG8g cmVxdWVzdHMgZm9sbG93IHRoZSBzYW1lIGRhdGEgcGF0aCB0aGF0IG5vcm1hbCBNUExTIHBhY2tl dHMgd291bGQgdHJhdmVyc2Uu4oCdIEkgZ3Vlc3MgdGhpcyBpcyBtYW5kYXRlZCBieSBvdGhlciBk b2N1bWVudHMsIHBsZWFzZSBhZGQgYSByZWZlcmVuY2UsIG90aGVyd2lzZSB0aGlzIGlzIGEgc3Ry b25nIHJlcXVpcmVtZW50IHRoYXQgbmVlZCB0byBiZSBzcGVjaWZpZWQgd2l0aCBSRkMyMTE5IHRl cm1pbm9sb2d5Lg0KICAqICAgTW90aXZhdGlvbjogKElDTVAgZWNobyByZXF1ZXN0IFtSRkMwNzky XS4gSXTigJlzIG5pY2UgdG8gaGF2ZSBhbGwgdGhlIHJlZmVyZW5jZXMgaW4gNCBkaWdpdHMsIGJ1 dCBJIGd1ZXNzIHRoZSAwIGlzIG5vdCBuZWVkZWQgYXQgdGhpcyB0aW1lLg0KICAqICAgU2VjdGlv biAyOiDigJxpcyBhIHB1cmUgUlNWUCBub2RlIGFuZCBkb2Ugbm90IHJ1biBMRFDigJ0gcy9kb2Vz L2RvZQ0KQlINCkRhbmllbGUNCg0K --_000_AM2PR07MB09942196213D9DC0F539DABFF0CC0AM2PR07MB0994eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLmljb24N Cgl7bXNvLXN0eWxlLW5hbWU6aWNvbjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVw dCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMzA3 NTExNjQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDMzOTM5MjMyO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjEyNTIwNzk0NjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTAxMjUxMTAwO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy NTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1s aXN0LWlkOjE1Mzg5Mjg1Mjc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4MDMwNDIyNjQ7fQ0K QGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7 bXNvLWxpc3QtaWQ6MTgyNTEyMTM2NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTc1MTY0OTkw MDt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NA0KCXttc28tbGlzdC1pZDoxOTM0OTY4NDE3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTM3 MDMzNjMyO30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0Omxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IklUIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5IZWxsbyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5z OiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVj dG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJh ZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywN CiBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJl dmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZTwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj48c3BhbiBjbGFzcz0iaWNvbiI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojNDQwMDg4Ij7igIs8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50 LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6YmxhY2siPkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlv dSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxs IGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZQ0KIHRoZW0g dGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1 cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjpibGFjayI+RG9jdW1lbnQ6PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OmJsYWNrIj5kcmFmdC1pZXRmLW1wbHMtcmZjNDM3OWJpcy0wNjxicj4NClJldmlld2VyOiBEYW5p ZWxlIENlY2NhcmVsbGk8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2si Pjxicj4NClJldmlldyBEYXRlOiAyNy8wOS8yMDE2PGJyPg0KSUVURiBMQyBFbmQgRGF0ZTogZGF0 ZS1pZi1rbm93bjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PGJy Pg0KSW50ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZCBUcmFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPldoZW4gSSBzYXcgdGhhdCB0aGUgZG9jdW1lbnQg d2FzIG9ic29sZXRpbmcgNCB3ZWxsIGtub3duIGFuZCB3aWRlbHkgZGVwbG95ZWQgZG9jdW1lbnRz IEkgd2FzIHNjYXJlZCwgYnV0IHJlYWRpbmcgdGhlIHNoZXBoZXJkIHdyaXRlIHVwIGl0IHNlZW1z IHRoYXQgdGhlIGRyYWZ0cyBnb3QgYSB3aWRlIGNvbnNlbnN1cw0KIGluIHRoZSB3b3JraW5nIGdy b3VwLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtm b250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtv cnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5TdW1tYXJ5Ojwvc3Bhbj48L3N0 cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5ObyBpc3N1ZXMgZm91bmQu IFRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Ryb25nPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+Q29tbWVudHM6PC9zcGFu Pjwvc3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxzdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrO2ZvbnQtd2VpZ2h0Om5vcm1hbCI+VGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRl biBhbmQgY29tcHJlaGVuc2libGUsIGJ1dCBJIGRpZG7igJl0IGV4cGVjdCBsZXNzIGZyb20gc3Vj aCBhIGRyZWFtIHRlYW0gb2YgYXV0aG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3A+ DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjpibGFjayI+TWFqb3IgSXNzdWVzOjwvc3Bhbj48L3N0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv cjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIj4mcXVvdDtObyBtYWpvciBpc3N1ZXMgZm91bmQuJnF1b3Q7PG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxp Z2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0 LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29y ZC1zcGFjaW5nOjBweCI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOmJsYWNrIj5NaW5vciBJc3N1ZXM6PC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkJhY2t3 YXJkIGNvbXBhdGliaWxpdHkuIEkgd291bGQgZXhwZWN0IHRvIHNlZSBhIHNlY3Rpb24gd2l0aCBz b21lIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzLiBQcm9iYWJseSBzaW5jZSBhbGwgdGhl IHByZXZpb3VzbHkgZGVmaW5lZCBtZXRob2RzIGFuZCBleHRlbnNpb25zIGFyZSBkZXByZWNhdGVk IG5vIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXMgZXhwZWN0ZWQ/IEluIGFueSBjYXNlIGl0IGlz IHdvcnRoDQogbWVudGlvbmluZyBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzQ7YmFja2dyb3Vu ZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+My4yLjguJm5ic3A7IEZFQyAxMjggUHNldWRv d2lyZSAtIElQdjQgKERlcHJlY2F0ZWQpIHZzLiAzLjIuOS4mbmJzcDsgRkVDIDEyOCBQc2V1ZG93 aXJlIC0gSVB2NCAoQ3VycmVudCkuIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoaXMuIElzIHRoZXJl IGEgZGVwcmVjYXRlZCB2ZXJzaW9uIG9mIHRoZSBGRUMgMTI4IFBXIGFuZCBhIGN1cnJlbnQgb25l PyBXaGVyZSBpcyB0aGF0IGRlcHJlY2F0ZWQ/IEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyB0aGUN CiBuZWVkIHRvIGFkZHJlc3MgYm90aCBidXQganVzdCB0aGUgY3VycmVudCBvbmUuIDxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Ryb25n PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+ Tml0czo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVs MSBsZm81O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgdGhp cyBzZW50ZW5jZSBjYW4gYmUgcmVtb3ZlZCBmcm9tIHRoZSBBYnN0cmFjdCDigJxUaGlzIGRvY3Vt ZW50IG9ic29sZXRlcyBSRkNzIDQzNzksIDY0MjQsIDY4MjksIGFuZCA3NTM3LuKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjaztt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsNCBsZXZlbDEgbGZvNTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5J bnRyb2R1Y3Rpb246ICZuYnNwO+KAnEFuIGltcG9ydGFudCBjb25zaWRlcmF0aW9uIGluIHRoaXMg ZGVzaWduIGlzIHRoYXQgTVBMUyBlY2hvIHJlcXVlc3RzIGZvbGxvdyB0aGUgc2FtZSBkYXRhIHBh dGggdGhhdCBub3JtYWwgTVBMUyBwYWNrZXRzIHdvdWxkIHRyYXZlcnNlLuKAnSBJIGd1ZXNzIHRo aXMgaXMgbWFuZGF0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzLCBwbGVhc2UgYWRkIGEgcmVmZXJlbmNl LCBvdGhlcndpc2UgdGhpcyBpcw0KIGEgc3Ryb25nIHJlcXVpcmVtZW50IHRoYXQgbmVlZCB0byBi ZSBzcGVjaWZpZWQgd2l0aCBSRkMyMTE5IHRlcm1pbm9sb2d5LjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDEg bGZvNTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5Nb3RpdmF0aW9uOiAo SUNNUCBlY2hvIHJlcXVlc3QgW1JGQzA3OTJdLiBJdOKAmXMgbmljZSB0byBoYXZlIGFsbCB0aGUg cmVmZXJlbmNlcyBpbiA0IGRpZ2l0cywgYnV0IEkgZ3Vlc3MgdGhlIDAgaXMgbm90IG5lZWRlZCBh dCB0aGlzIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm81O2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gMjog4oCcaXMgYSBwdXJlIFJTVlAgbm9kZSBhbmQg ZG9lIG5vdCBydW4gTERQ4oCdIHMvZG9lcy9kb2U8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hp dGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+QlI8YnI+DQpEYW5p ZWxlJm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM2PR07MB09942196213D9DC0F539DABFF0CC0AM2PR07MB0994eurp_-- From nobody Wed Sep 28 07:02:28 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAB412B629; Wed, 28 Sep 2016 07:02:26 -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, 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 hMmAsMT_bdv1; Wed, 28 Sep 2016 07:02:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B3212B4B3; Wed, 28 Sep 2016 07:02:16 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id DDBE0F8E1E603; Wed, 28 Sep 2016 14:02:11 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u8SE2D1l006348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Sep 2016 14:02:14 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u8SE29RM024666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Sep 2016 16:02:13 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.121]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Wed, 28 Sep 2016 16:02:11 +0200 From: "Bocci, Matthew (Nokia - GB)" To: "draft-ietf-rtgwg-uloop-delay@tools.ietf.org" Thread-Topic: Rtg Area Directorate QA review of draft-ietf-rtwg-uloop-delay-02.txt Thread-Index: AQHSGZDo93v4FKKf3UWkB0E0kRj+Tw== Date: Wed, 28 Sep 2016 14:02:11 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.1.160916 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_F485324D095142FD8403E116A6152589nokiacom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "rtgwg-chairs@tools.ietf.org" , "rtgwg@ietf.org" Subject: Re: [RTG-DIR] Rtg Area Directorate QA review of draft-ietf-rtwg-uloop-delay-02.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 14:02:27 -0000 --_000_F485324D095142FD8403E116A6152589nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXBvbG9naWVzIGZvciB0aGUgbXVsdGlwbGUgY29waWVzLiBBZGRpbmcgUlRHIERpci4NCg0KTWF0 dGhldw0KDQpGcm9tOiAiQm9jY2ksIE1hdHRoZXcgKE5va2lhIC0gR0IpIiA8bWF0dGhldy5ib2Nj aUBub2tpYS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIDI4IFNlcHRlbWJlciAyMDE2IGF0IDExOjIy DQpUbzogImRyYWZ0LWlldGYtcnRnd2ctdWxvb3AtZGVsYXlAdG9vbHMuaWV0Zi5vcmciIDxkcmFm dC1pZXRmLXJ0Z3dnLXVsb29wLWRlbGF5QHRvb2xzLmlldGYub3JnPg0KQ2M6ICJydGd3Zy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmciIDxydGd3Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCAicnRnd2dA aWV0Zi5vcmciIDxydGd3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJ0ZyBBcmVhIERpcmVjdG9yYXRl IFFBIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0d2ctdWxvb3AtZGVsYXktMDIudHh0DQoNCkF1dGhv cnMsDQoNCkkgaGF2ZSBiZWVuIGFza2VkIHRvIGRvIGEgUm91dGluZyBBcmVhIERpcmVjdG9yYXRl IFFBIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0d2ctdWxvb3AtZGVsYXktMDIudHh0DQoNCg0KDQpT dW1tYXJ5Og0KDQpUaGUgcmF0aW9uYWxlIGZvciB0aGlzIGRvY3VtZW50IGlzIGNsZWFyIGFuZCB0 aGUgbWVjaGFuaXNtIHNlZW1zIHJlYXNvbmFibHkgc3RyYWlnaHQgZm9yd2FyZC4gSG93ZXZlciwg b25lIG1ham9yIGNvbW1lbnQgdGhhdCBJIGhhdmUgaXMgdGhhdCB0aGUgRW5nbGlzaCBncmFtbWFy IGlzIHBvb3IgaW4gc29tZSBzZWN0aW9ucywgYW5kIGl0IGlzIG1pc3Npbmcgbm9ybWFsIEVuZ2xp c2ggYXJ0aWNsZXMgaW4gc29tZSBwbGFjZXMgKGEsIGFuLCB0aGUs4oCmKSwgbWFraW5nIGl0IGhh cmQgdG8gcmVhZC4gSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIGF1dGhvcnMgZ28gdGhyb3VnaCB0 aGUgZHJhZnQgd2l0aCBhIG5hdGl2ZSBFbmdsaXNoIHNwZWFrZXIgdG8gaGVscCByZXNvbHZlIHRo ZXNlIG5pdHMuDQoNCg0KQ29tbWVudHM6DQoNCk1pbm9yIElzc3VlczoNCg0KU2VjdGlvbiAyLjEg RmFzdCByZXJvdXRlIHVuZWZmaWNpZW5jeQ0Kcy91bmVmZmljaWVuY3kvaW5lZmZpY2llbmN5DQoN ClNlY3Rpb24gNC4xIERlZmluaXRpb25zLCAybmQgYnVsbGV0Og0K4oCmYnkgaW5jcmVtZW50aW5n IHRoZSB0aW1lciB2YXBlIHdoZW4gdGhlIElHUCBpcyBpbnN0YWJsZS4NCnMvaW5zdGFibGUvdW5z dGFibGUNCg0KNC4zIExvY2FsIEV2ZW50cw0KVGhlIGRyYWZ0IHN0YXRlcyB0aGF0IGl0IGFzc3Vt ZXMgdGhhdCBvbmx5IGEgc2luZ2xlIGxpbmsgZmFpbHVyZSBoYXMgYmVlbiBzZWVuIGJ5IHRoZSBJ R1AgYXJlYS4gSG93ZXZlciwgaXRzIG5vdCBjbGVhciBob3cgeW91IGRpc3Rpbmd1aXNoIGEgc2lu Z2xlIGxvY2FsIGZhaWx1cmUgZnJvbSBjb25zZWN1dGl2ZSAobm9uLXNpbXVsdGFuZW91cykgZmFp bHVyZSB0aGF0IG9jY3VycyB3aXRoaW4gYSBnaXZlbiBzaG9ydCB0aW1lc3BhbiBlLmcuIGR1cmlu ZyB0aGUgaW5pdGlhbCByZS1jb252ZXJnZW5jZSBwZXJpb2QuIEl0IHdvdWxkIGhlbHAgdG8gY2xh cmlmeSB0aGlzLg0KDQpSZWdhcmRzDQoNCk1hdHRoZXcNCg== --_000_F485324D095142FD8403E116A6152589nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <57CA4AABC8D0F64D80B6D35C886A6F1E@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFw b2xvZ2llcyBmb3IgdGhlIG11bHRpcGxlIGNvcGllcy4gQWRkaW5nIFJURyBEaXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5NYXR0aGV3PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJv bTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O0JvY2NpLCBNYXR0 aGV3IChOb2tpYSAtIEdCKSZxdW90OyAmbHQ7bWF0dGhldy5ib2NjaUBub2tpYS5jb20mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgMjggU2VwdGVtYmVyIDIwMTYgYXQgMTE6MjI8YnI+ DQo8Yj5UbzogPC9iPiZxdW90O2RyYWZ0LWlldGYtcnRnd2ctdWxvb3AtZGVsYXlAdG9vbHMuaWV0 Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0LWlldGYtcnRnd2ctdWxvb3AtZGVsYXlAdG9vbHMuaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtydGd3Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcm cXVvdDsgJmx0O3J0Z3dnLWNoYWlyc0B0b29scy5pZXRmLm9yZyZndDssICZxdW90O3J0Z3dnQGll dGYub3JnJnF1b3Q7ICZsdDtydGd3Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UnRnIEFyZWEgRGlyZWN0b3JhdGUgUUEgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnR3Zy11bG9vcC1k ZWxheS0wMi50eHQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkF1dGhvcnMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgYmVlbiBh c2tlZCB0byBkbyBhIFJvdXRpbmcgQXJlYSBEaXJlY3RvcmF0ZSBRQSByZXZpZXcgb2YgZHJhZnQt aWV0Zi1ydHdnLXVsb29wLWRlbGF5LTAyLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5TdW1tYXJ5OiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlRoZSByYXRpb25hbGUgZm9yIHRoaXMgZG9jdW1lbnQgaXMgY2xlYXIgYW5kIHRoZSBtZWNo YW5pc20gc2VlbXMgcmVhc29uYWJseSBzdHJhaWdodCBmb3J3YXJkLiBIb3dldmVyLCBvbmUgbWFq b3IgY29tbWVudCB0aGF0IEkgaGF2ZSBpcyB0aGF0IHRoZSBFbmdsaXNoIGdyYW1tYXIgaXMgcG9v ciBpbiBzb21lIHNlY3Rpb25zLCBhbmQgaXQgaXMgbWlzc2luZw0KIG5vcm1hbCBFbmdsaXNoIGFy dGljbGVzIGluIHNvbWUgcGxhY2VzIChhLCBhbiwgdGhlLOKApiksIG1ha2luZyBpdCBoYXJkIHRv IHJlYWQuIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBhdXRob3JzIGdvIHRocm91Z2ggdGhlIGRy YWZ0IHdpdGggYSBuYXRpdmUgRW5nbGlzaCBzcGVha2VyIHRvIGhlbHAgcmVzb2x2ZSB0aGVzZSBu aXRzLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Q29tbWVudHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5NaW5vciBJc3N1ZXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5TZWN0aW9uIDIuMSBGYXN0IHJlcm91dGUgdW5lZmZpY2llbmN5PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPnMvdW5lZmZpY2llbmN5L2luZWZmaWNpZW5jeTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjdGlvbiA0LjEgRGVmaW5pdGlvbnMsIDJuZCBi dWxsZXQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKApmJ5IGluY3JlbWVudGluZyB0aGUgdGltZXIgdmFw ZSB3aGVuIHRoZSBJR1AgaXMgaW5zdGFibGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnMvaW5zdGFibGUv dW5zdGFibGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjQuMyBM b2NhbCBFdmVudHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGRyYWZ0IHN0YXRlcyB0aGF0IGl0IGFz c3VtZXMgdGhhdCBvbmx5IGEgc2luZ2xlIGxpbmsgZmFpbHVyZSBoYXMgYmVlbiBzZWVuIGJ5IHRo ZSBJR1AgYXJlYS4gSG93ZXZlciwgaXRzIG5vdCBjbGVhciBob3cgeW91IGRpc3Rpbmd1aXNoIGEg c2luZ2xlIGxvY2FsIGZhaWx1cmUgZnJvbSBjb25zZWN1dGl2ZSAobm9uLXNpbXVsdGFuZW91cykg ZmFpbHVyZQ0KIHRoYXQgb2NjdXJzIHdpdGhpbiBhIGdpdmVuIHNob3J0IHRpbWVzcGFuIGUuZy4g ZHVyaW5nIHRoZSBpbml0aWFsIHJlLWNvbnZlcmdlbmNlIHBlcmlvZC4gSXQgd291bGQgaGVscCB0 byBjbGFyaWZ5IHRoaXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1h dHRoZXcgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F485324D095142FD8403E116A6152589nokiacom_-- From nobody Wed Sep 28 07:02:57 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C44912B0FC; Wed, 28 Sep 2016 07:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 qGtd9v4HSS5P; Wed, 28 Sep 2016 07:02:52 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B667A12B62D; Wed, 28 Sep 2016 07:02:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u8SD4iqg017183; Wed, 28 Sep 2016 14:04:44 +0100 Received: from 950129200 (215.142.200.146.dyn.plus.net [146.200.142.215]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u8SD4hUt017167 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 28 Sep 2016 14:04:44 +0100 From: "Adrian Farrel" To: Date: Wed, 28 Sep 2016 14:04:42 +0100 Message-ID: <058601d21988$e15b2820$a4117860$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIZiNhgJFYL6aUFSdWje399fj4r5g== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22604.007 X-TM-AS-Result: No--14.552-10.0-31-10 X-imss-scan-details: No--14.552-10.0-31-10 X-TMASE-MatchedRID: 7ikih+lHaLXzLVZFOZrw3hes/RxhysDbFJFr2qlKix9V84HrPxCfbDMB KS/l5ik348guxdxp7TO00HTgX5ZI96z75DRX+d9kKWuiyZLRI4Bu/Xr6CKXiN8sIWSRjI55e5Fu sfEwDqdCt0TdzqXhHAKl8sEIkt5BhOg4q4lJPNt/TzWmGCXkX+dRmti/O6j0CXCmcAC8DBrP0FA Va72o9hszgY8pfC4TTOHY3aadbY80xjoug6afrr54RyjTmGyy+y1y/jIuoZZ4OU/uP6vRQHOtEC hJEb/RrGo9USpPKL38g7N05Mw+AaZRMdwEiWk2NiguiJuCNURc0AKed0u9fB1pbYq2f4jz+EfPY ETCOeBC9ivu5r56wpIFEKqw2CUrwD/RMXi4yHpDhqJ6oLOc8QQSUf28NGWiYEoJn5DrIHypzLiy pTPAGOx7NcPIGQZP5HDzDwZlZOvCxxK6sBu9wbgphJ/svEmvGWwKGivsEuI3AZ14rz+novkodGV 1LGob5fAHeBIDxxkNGlyZtRTr6W4x1g1lTiexdjFUG+PWNtyPyVbjbSjLWDDdnd59Af7CPuOiT3 BKFjXuA0sySfBH+KuVgG/pXepgmlyrPeDQDh/KRVQzJVQpFnl4KsHfYo5LQEB/Asc4oaYF6RaSp HJq/AFfrVjHokffYIg3S9zgZG042H9WVrLaFbfO4FPWGZksPocSvEPKGO+fKI9dJdjFW2HGQNpi MCHiz0zA3ckbt+IS/nh1kA/2bjVLx2/FSLvaEkmtbTcNpxYRG27i+2OO3NJzYFsVjIMcyEbn1ju 1WGDHY0jno/xmKISMCJpXHrywcexFW7fkMi0yeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0ePs 7A07cNbTFVOzjU8oM9HE45P5yQ3GoHXHT22nA5u4Q8Bzfg5yszCl8d17xE= Archived-At: Cc: draft-ietf-pals-status-reduction.all@ietf.org, rtg-dir@ietf.org, pals@ietf.org Subject: [RTG-DIR] RtgDir review of draft-ietf-pals-status-reduction-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2016 14:02:56 -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-pals-status-reduction-01.txt Reviewer: Adrian Farrel Review Date: 27 September 2016 IETF LC End Date: Not yet started Intended Status: Standards Track ==Summary:== I have some minor concerns about this document that I think should be resolved before publication. The volume of minor concerns add up to a significant concern although no one issue is large. I recommend that the Routing ADs discuss these issues further with the authors and consider whether an updated I-D would need to be re-reviewed by the WG. ==Comments:== This document defines a mechanism to "bundle" status reports on the PWs carried on an MPLS tunnel. The effect is to significantly reduce the number of messages need in the (normal) stable state. I don't see any problems with the mechanism defined and I am sure it would work. The writing style is mainly clear. However, there is a host of minor issues and holes in the documentation that puts the specification below the level necessary to guarantee interoperable implementations. My review is not as an implementer, and it worries me that if I find so many questions and issues, an implementer would find far more. I checked to see whether anyone had commented in WGLC that they had read the document and I didn't see anything (perhaps my list subscription is broken?) ==Minor Issues:== Section 1.3 I think you need to give a reference for the base BNF you are using. You could choose from RFC 5234 or RFC 5511. But it seems peculiar that you have set out to define your own notation for things that can be expressed in existing BNF. Section 4 The figure makes it look like MPLS labels are 32 bits long. I guess you could fix this by s/label/label stack entry/ Or you could show all of the LSE fields. Section 4 You have not described all of the fields in the figure. Section 4 You have... Channel type 0xZZ pending IANA allocation. ...but no mention in the IANA section The figure shows "0xZZ PW OAM Message", but surely this is "PW Status Reduction Message" Section 4 In the description of the Session ID CRC16 seed really "recommended"? I mean, is this "RECOMMENDED", and if so, why? You *do* need a locally selected, locally unique value. It does not need to be unique over time, but you may need suggest a damping mechanism on re-use of session ID. However, recommending this mechanism for generating session IDs seems to me to be over-weaning. What is the reason? Section 4 There are a number of rules expressed here about the setting of the message fields (such as the Refresh Timer that is a "non zero unsigned 16 bit integer value greater or equal to 10"). What happens if a message is received that violates one of these rules. Section 4 OLD 7 bits of flags reserved for future use, they MUST be set to 0 on transmission, and ignored on reception. NEW 6 bits of flags reserved for future use, they MUST be set to 0 on transmission, and ignored on reception. END Section 4 Do you want IANA to track the flags field? Section 4 You have... It should be noted that the Checksum, Message Sequence Number, Last Received Message Sequence Number, Message Type, Flags, and control message body are OPTIONAL. This *sounds* like each field is individually optional. But that is not the case, I think (because the resulting message would be impossible to parse). So you need to clarify. Probably that the length field indicates where the sequence stops, or that the whole set may be omitted or included en mass. Section 5 opening paragraphs are confusing. Either you have a "control message" or you have a "control construct carried on a status reduction message". - It is possible you mean the former. That is "There are two status reduction messages defined in this document and they are both control messages: the Notification message and the PW Configuration message. - It is possible you mean have the latter. Thus, when you talk about the "message sequence number of the control message" you really mean the "message sequence number of the status reduction message that carries the control construct". You can probably note that the control construct can be carried on a Notification message or a PW Configuration message. You should probably also say whether the control construct can be carried on other (future) messages. Section 5 In 8.3 you list a number of notification codes. A little can be deduced from their names, but you do not describe anywhere when or why most of them are used (5.0.2.3 and 6 are the exceptions). You should, and section 5 or 6 is probably the place. Section 5.0.1 What is the setting of the C flag on the Notification message? Section 5.0.2 The message has no preset length limit, however its total length will be limited by the transport network Maximum Transmit Unit (MTU). This is fine, however: - You probably want to add "Status Reduction messages MUST NOT be fragmented." - You probably also want "If a sender has more configuration information to send than will fit into one PW Configuration Message it may send further messages carrying further TLVs." Section 5.0.2 I think you need to define a generic TLV format so that new TLVs can be added and parsed over. Since you use a common format for your TLVs, this should not be hard. However, you also need to describe how "unknown" TLVs are handled. Section 5.0.2.1 Is the MPLS-TP Tunnel ID TLV optional? 5.0.2.2 shows the PW ID configured List TLV as optional, so it looks like the MPLS-TP Tunnel ID might be mandatory TLV. Furthermore, you seem to have said that the order of TLVs is arbitrary but wouldn't it be best to have this TLV show up first? What happens if there are multiple of this TLV present? Section 5.0.2.2 (and 5.0.2.3) The number of PW Path IDs in the TLV will be inferred by the length of the TLV up to a maximum of 8. Now, "The PW Path ID is a 32 octet pseudowire path identifier" 8*32=256 The Length field has 8 bits and so encodes a maximum of 255 octets. So you can actually only carry 7 PW Path IDs in this TLV. Furthermore, Length values that are not a multiple of 32 are an encoding error, but you haven't stated how to handle encoding errors. What happens if the same PW Path ID appears twice in a list? Section 6 A PE that desires to use the PW configuration message to verify the configuration of PWs on a particular LSP, should advertise its PW configuration to the remote PE on LSPs that have active keepalive sessions. I think that probably hidden in here is "MUST NOT include a PW configuration message on a status reduction message unless the local protocol state is ACTIVE." Section 6 the following action SHOULD be taken: -i. The local PW MUST be considered in "Not Forwarding" State. That creates a composite "SHOULD-MUST" which is not very clear. Suggest you change to... the following actions are taken: -i. MUST -ii. SHOULD -iii. SHOULD Section 7 Why does this section not discuss the Checksum field? Doesn't this add a measure of security (at least against simple, random attacks)? Should you also give guidance (here or in section 4) about when it is acceptable to use a zero checksum. Section 8.1 - meta-point to be addressed before the following issue with this section... You seem to have an overly-complex assignment policy for this registry. All of the types seem to have equal weight (i.e., there are no "special purpose" values yet you cover the range with: - Expert review - IETF review - FCFS Since FCFS guarantees an assignment without any further review, why would anyone bother with Expert Review. For that matter, why would anyone bother with IETF Review? So, why not make life easier and say all code points are FCFS? Section 8.1 s/IETF consensus/IETF review/ Section 8.1 You have a range assigned by Expert Review. It is a requirement that you give guidance to the experts about how they should review requests. Section 8.1 The values 128 through 254 are assigned using FCFS. You cannot then attempt to further constrain how the values are used (e.g., "for vendor proprietary extensions"), and you should avoid the word "reserved" since it has special meaning for IANA. Section 8.2 I have essentially an identical set of points about 8.2 carried from 8.1 Section 8.3 Again the same set of comments. Additionally, you need to tell IANA what the "Error?" column means. This is probably... For each value assigned IANA should also track whether the value constitutes an error as described in Section 5.0.1. When values are assigned by IETF Review, the setting of this column must be documented in the RFC that requests the allocation. For Expert Review and FCFS assignments, the setting of this column must be made clear by the requested at the time of assignment. ==Nits:== I believe Luca may want to change his reported affiliation. Abstract OLD This document describes a method for generating an aggregated pseudowire status message on Multi-Protocol Label Switching (MPLS) network Label Switched Path (LSP). NEW This document describes a method for generating an aggregated pseudowire status message transmitted on a Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) to indicate the status of one or more pseudowires carried on the LSP. END Introduction Expand "PW" on first use. s/they are setup/they are set up/ Section 2 "MPLS Generic Associated Channel" needs a reference to 5586 Throughout the document you need to be consistent (and with prior art) about capitalisation ("generic associated channel" or "Generic Associated Channel" etc.) and abbreviations ("GACH" or "G-ACh" etc.) Section 4 Message Sequence Number s/A unsigned/An unsigned/ Section 4 (from the figure) OLD | Last Received Seq Number | Message Type |U C Flags | NEW | Last Received Seq Number | Message Type |U|C|Flags | END Section 4 Unknown flag bit. s/MUST be acknowledge/MUST be acknowledged/ The sub-section numbering in Section 5 is broken. You can have, for example, "5.0.1". In a number of places you have "sub-TLVs" and in other places "TLVs". I think they are all "TLVs". In 5.0.2.1 "the address of the MPLS-TP tunnel ID" is confused. It is "the identifier of the MPLS tunnel". Indeed, where did MPLS-TP suddenly come from since you want this to work for all LSPs (see also 8.2). 2.1.1, 2.1.3, and 5.0.2.3 "unprovisioned" I think the word is "deprovisioned" Section 6 If a PE receives such a notification it should stop sending PW configuration control messages for the duration of the PW refresh reduction keepalive session. s/should/SHOULD/ Section 8 All the registries in this section are to be created or updated as apropriate in the PW Name Spaces. No such name space error. I think you mean "Pseudowire Name Spaces (PWE3)" s/apropriate/appropriate/ s/10. Author's Addresses/10. Authors' Addresses/ From nobody Thu Sep 29 10:05:27 2016 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E77812B216; Thu, 29 Sep 2016 10:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.836 X-Spam-Level: X-Spam-Status: No, score=-16.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5uJvHdNcYYr; Thu, 29 Sep 2016 10:05:23 -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 30CAB12B582; Thu, 29 Sep 2016 10:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32598; q=dns/txt; s=iport; t=1475168660; x=1476378260; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YKVmbjeyAO28gMCY8xkT2TKyNmw6fPPoBahVBMVARaI=; b=OmY5UG4FMyrmgnLKDLC2n/hhuU0US+Ouawed/h6IN/XMoQMgFkgU15i6 haoTM4C79WqZnsOT55cqTiuo4jFhGbs4wprSeJP5fjTNJQbNATb58ze3n UfYB1JFWIOvJEJBd3rR6BhBAUFctwjs9mJ/bK0nkVXszg9jH0Gc/On4Tb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQDWSO1X/5ldJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMJNgEBAQEBHld8B40rlnyUI4IGJIV6AhyBSDgUAQIBAQEBAQE?= =?us-ascii?q?BXieEYgEBBCNWEAIBBgIUJAcDAgICMBQRAQEEDgWITQ6RfJ0mjGkBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEchjeBfQiCUIQcPwmCZCuCLwWIK4tfFYVYAYYmiUmBbk6?= =?us-ascii?q?EGIQ2hGSHJIVIg3wBDw82gx0cgVByAQEBAYZCgQABAQE?= X-IronPort-AV: E=Sophos;i="5.31,415,1473120000"; d="scan'208,217";a="154611884" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2016 17:04:18 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u8TH4IVB020617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Sep 2016 17:04:18 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Sep 2016 13:04:17 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 29 Sep 2016 13:04:17 -0400 From: "Carlos Pignataro (cpignata)" To: Daniele Ceccarelli Thread-Topic: RtgDir review: draft-ietf-mpls-rfc4379bis-06 Thread-Index: AdIYlGctmue+loOwTiq6Dd9Tc8UYiACAKL6A Date: Thu, 29 Sep 2016 17:04:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.20] Content-Type: multipart/alternative; boundary="_000_DB7AE56F937646F798A078843CB5901Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: " \(rtg-ads@ietf.org\)" , "rtg-dir@ietf.org" , "draft-ietf-mpls-rfc4379bis.all@ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-rfc4379bis-06 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 17:05:25 -0000 --_000_DB7AE56F937646F798A078843CB5901Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIERhbmllbGUsDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldyEgUGxlYXNlIGZp bmQgbXkgZm9sbG93LXVwcyBpbmxpbmUuDQoNCkRlYm9yYWgsDQoNCi0wNyAoanVzdCBwb3N0ZWQp IGFkZHJlc3NlcyB0aGVzZSBjb21tZW50cy4NCg0KT24gU2VwIDI3LCAyMDE2LCBhdCA1OjAwIEFN LCBEYW5pZWxlIENlY2NhcmVsbGkgPGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208bWFp bHRvOmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KDQpIZWxsbywN Cg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgcmV2aWV3 ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmll dyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJv dWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVj aWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Np c3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjxodHRwOi8vdHJhYy50b29scy5pZXRmLm9y Zy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPg0KDQpBbHRob3VnaCB0aGVzZSBjb21tZW50cyBh cmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUg aGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJ RVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJl c29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRyYWZ0Lg0K DQpEb2N1bWVudDogZHJhZnQtaWV0Zi1tcGxzLXJmYzQzNzliaXMtMDYNClJldmlld2VyOiBEYW5p ZWxlIENlY2NhcmVsbGkNClJldmlldyBEYXRlOiAyNy8wOS8yMDE2DQpJRVRGIExDIEVuZCBEYXRl OiBkYXRlLWlmLWtub3duDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkIFRyYWNrDQoNCldoZW4g SSBzYXcgdGhhdCB0aGUgZG9jdW1lbnQgd2FzIG9ic29sZXRpbmcgNCB3ZWxsIGtub3duIGFuZCB3 aWRlbHkgZGVwbG95ZWQgZG9jdW1lbnRzIEkgd2FzIHNjYXJlZCwgYnV0IHJlYWRpbmcgdGhlIHNo ZXBoZXJkIHdyaXRlIHVwIGl0IHNlZW1zIHRoYXQgdGhlIGRyYWZ0cyBnb3QgYSB3aWRlIGNvbnNl bnN1cyBpbiB0aGUgd29ya2luZyBncm91cC4NCg0KU3VtbWFyeToNCk5vIGlzc3VlcyBmb3VuZC4g VGhpcyBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOg0KDQpU aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCBjb21wcmVoZW5zaWJsZSwgYnV0IEkgZGlk buKAmXQgZXhwZWN0IGxlc3MgZnJvbSBzdWNoIGEgZHJlYW0gdGVhbSBvZiBhdXRob3JzLg0KDQpU aGFuayB5b3UgZm9yIHRoZSBkb2N1bWVudCBzdW1tYXJ5IGFib3ZlISA6LSkNCg0KTWFqb3IgSXNz dWVzOg0KDQogICogICAiTm8gbWFqb3IgaXNzdWVzIGZvdW5kLiINCg0KTWlub3IgSXNzdWVzOg0K DQogICogICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBJIHdvdWxkIGV4cGVjdCB0byBzZWUgYSBz ZWN0aW9uIHdpdGggc29tZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3Vlcy4gUHJvYmFibHkg c2luY2UgYWxsIHRoZSBwcmV2aW91c2x5IGRlZmluZWQgbWV0aG9kcyBhbmQgZXh0ZW5zaW9ucyBh cmUgZGVwcmVjYXRlZCBubyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIGV4cGVjdGVkPyBJbiBh bnkgY2FzZSBpdCBpcyB3b3J0aCBtZW50aW9uaW5nIGl0Lg0KDQpUaGlzIGlzIGEgZ29vZCBwb2lu dC4gTXkgdGFrZSB3b3VsZCBiZSB0aGF0IGFzIHRoZSBkZXByZWNhdGVkIGVsZW1lbnRzIGFyZSBu b3QgcGFydCBvZiB0aGUgc3BlY2lmaWNhdGlvbiAodGhleSBhcmUgbW92ZWQgZG93biB0byBhIG5v bi1ub3JtYXRpdmUgYXBwZW5kaXggZm9yIGNvbXBsZXRlbmVzcyksIHRoZW4gYXMgeW91IHNheSB0 aGVyZSBpcyBubyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eS4NCg0KVGhpcyBkb2N1bWVudCBkb2Vz IG5vdCB2ZXJzaW9uKysgdGhlIHByb3RvY29sLg0KDQpPbmUgdGhpbmcgd2Ugc2hvdWxkIGRvIGlz IG1ha2UgbW9yZSBjbGVhciB0aGF0IEFwcGVuZGl4IEEgaXMgbm9uLW5vcm1hdGl2ZSBmb3IgYW4g aW1wbGVtZW50YXRpb24uIEkgY2FuIGFkZCBhIHNlbnRlbmNlIHRoZXJlLCBoZXJl4oCZcyBvbmUg c3VnZ2VzdGlvbiBmb3IgdGhlIFdHIHRvIGNvbnNpZGVyOg0KDQogIDxzZWN0aW9uIHRpdGxlPSJE ZXByZWNhdGVkIFRMVnMgYW5kIHN1Yi1UTFZzIChOb24tbm9ybWF0aXZlKSI+DQo8dD4NClRoaXMg YXBwZW5kaXggZGVzY3JpYmVzIGRlcHJlY2F0ZWQgZWxlbWVudHMsIHdoaWNoIGFyZSBub24tbm9y bWF0aXZlIGZvciBhbiBpbXBsZW1lbnRhdGlvbi4NClRoZXkgYXJlIGluY2x1ZGVkIGluIHRoaXMg ZG9jdW1lbnQgZm9yIGhpc3RvcmljYWwgYW5kIGluZm9ybWF0aW9uYWwgcHVycG9zZXMuDQo8L3Q+ DQoNCg0KDQogICoNCiAgKiAgIDMuMi44LiAgRkVDIDEyOCBQc2V1ZG93aXJlIC0gSVB2NCAoRGVw cmVjYXRlZCkgdnMuIDMuMi45LiAgRkVDIDEyOCBQc2V1ZG93aXJlIC0gSVB2NCAoQ3VycmVudCku IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoaXMuIElzIHRoZXJlIGEgZGVwcmVjYXRlZCB2ZXJzaW9u IG9mIHRoZSBGRUMgMTI4IFBXIGFuZCBhIGN1cnJlbnQgb25lPyBXaGVyZSBpcyB0aGF0IGRlcHJl Y2F0ZWQ/IEkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyB0aGUgbmVlZCB0byBhZGRyZXNzIGJvdGgg YnV0IGp1c3QgdGhlIGN1cnJlbnQgb25lLg0KDQpZZXMsIHRoaXMgaXMgY29taW5nIGZyb20gUkZD IDQzNzkgYmVjYXVzZSB0aGUgb3JpZ2luYWxseSBkZWZpbmVkIEZFQyAxMjggd2l0aG91dCB0aGUg U2VuZGVy4oCZcyBJUCh2NCkgYWRkcmVzcywgYW5kIHdhcyBkZXByZWNhdGVkIGJlY2F1c2UgaXQg ZG9lcyBub3QgdW5pdm9jYWxseSBpZGVudGlmeSB0aGUgRkVDIOKAlCB0aGUg4oCcY3VycmVudOKA nSB3YXMgdGhlbiBhZGRlZCwgY29uc2VxdWVudGx5LiBUaGlzIGRvY3VtZW50IGtlZXBzIHRoZSDi gJxkZXByZWNhdGVk4oCdIHZlcnNpb27igJlzIHRpdGxlIGFuZCBJQU5BIG51bWJlciwgYnV0IG1v dmVkIHRoZSBkZWZpbml0aW9uIHRvIGFuIEFwcGVuZGl4Lg0KDQoNCiAgKg0KDQpOaXRzOg0KDQog ICogICBJIHRoaW5rIHRoaXMgc2VudGVuY2UgY2FuIGJlIHJlbW92ZWQgZnJvbSB0aGUgQWJzdHJh Y3Qg4oCcVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDcyA0Mzc5LCA2NDI0LCA2ODI5LCBhbmQg NzUzNy7igJ0NCg0KSXTigJlzIG5lY2Vzc2FyeSBhcyBwZXIgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWQtaW5mby9jaGVja2xpc3QuaHRtbCNhbmNob3I2DQoNCiAgKg0KICAqICAgSW50cm9kdWN0aW9u OiAg4oCcQW4gaW1wb3J0YW50IGNvbnNpZGVyYXRpb24gaW4gdGhpcyBkZXNpZ24gaXMgdGhhdCBN UExTIGVjaG8gcmVxdWVzdHMgZm9sbG93IHRoZSBzYW1lIGRhdGEgcGF0aCB0aGF0IG5vcm1hbCBN UExTIHBhY2tldHMgd291bGQgdHJhdmVyc2Uu4oCdIEkgZ3Vlc3MgdGhpcyBpcyBtYW5kYXRlZCBi eSBvdGhlciBkb2N1bWVudHMsIHBsZWFzZSBhZGQgYSByZWZlcmVuY2UsIG90aGVyd2lzZSB0aGlz IGlzIGEgc3Ryb25nIHJlcXVpcmVtZW50IHRoYXQgbmVlZCB0byBiZSBzcGVjaWZpZWQgd2l0aCBS RkMyMTE5IHRlcm1pbm9sb2d5Lg0KDQoNCkEgcmVxdWlyZW1lbnQgZG9lcyBub3QgbmVlZCB0byBj b21lIGZyb20gYSBkaWZmZXJlbnQgKGUuZy4sIOKAnFJlcXVpcmVtZW50c+KAnSkgZG9jdW1lbnQg YW5kIEkgdGhpbmsgdGhhdCB0aGlzIGRvY3VtZW50IGNhbiBpbmNsdWRlIHRoYXQgZGVzaWduIGNy aXRlcmlhIHVwIGZyb250LCBhcyBsb25nIGFzIGl0IGlzIGNsZWFyIGFuZCB0cmFuc3BhcmVudCwg d2l0aG91dCBmaW5kaW5nIGEgY2l0YXRpb24uDQoNCkkgYW0gaGVzaXRhbnQgdG8gYXJ0aWZpY2lh bGx5IGNoYXNlIGEgY2l0YXRpb24gdGhhdCB3YXMgbm90IGluIFJGQyA0Mzc5LiBUaGF0IHNhaWQs IGlmIHRoZSBXRyB3YW50cyB3ZSBjYW4gZmluZCBzb21ldGhpbmcgYW5kIGFkZCBpdCAobGlrZSBm cm9tIDQzNzcgbWF5YmUpIOKAlCB0aG91Z2ggSSBwcm9iYWJseSB3b3VsZG7igJl0Lw0KDQogICoN CiAgKiAgIE1vdGl2YXRpb246IChJQ01QIGVjaG8gcmVxdWVzdCBbUkZDMDc5Ml0uIEl04oCZcyBu aWNlIHRvIGhhdmUgYWxsIHRoZSByZWZlcmVuY2VzIGluIDQgZGlnaXRzLCBidXQgSSBndWVzcyB0 aGUgMCBpcyBub3QgbmVlZGVkIGF0IHRoaXMgdGltZS4NCg0KV2hhdGV2ZXIgeG1sMnJmYyByZW5k ZXJzIDotKSBUaGUgYW5jaG9yIGluIHRoZSBiaWJ4bWwgaW5jbHVkZXMgdGhlIOKAnDDigJ0uIGh0 dHBzOi8veG1sMnJmYy50b29scy5pZXRmLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu UkZDLjA3OTIueG1sDQoNCg0KICAqDQogICogICBTZWN0aW9uIDI6IOKAnGlzIGEgcHVyZSBSU1ZQ IG5vZGUgYW5kIGRvZSBub3QgcnVuIExEUOKAnSBzL2RvZXMvZG9lDQoNCkZpeGVkLg0KDQpUaGFu a3MgYWdhaW4hDQoNCuKAlCBDYXJsb3MuDQoNCg0KICAqDQoNCkJSDQpEYW5pZWxlDQoNCg== --_000_DB7AE56F937646F798A078843CB5901Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0D44ACCEF25AAA4BB14A08B236AA969B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sIERhbmllbGUsDQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYW55IHRoYW5r cyBmb3IgeW91ciByZXZpZXchIFBsZWFzZSBmaW5kIG15IGZvbGxvdy11cHMgaW5saW5lLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RGVi b3JhaCw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPi0wNyAoanVzdCBwb3N0ZWQpIGFkZHJlc3NlcyB0aGVzZSBjb21tZW50cy48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMjcsIDIwMTYsIGF0IDU6MDAgQU0s IERhbmllbGUgQ2VjY2FyZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmllbGUuY2VjY2FyZWxs aUBlcmljc3Nvbi5jb20iIGNsYXNzPSIiPmRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFn ZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxwIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBjbTsg bWFyZ2luLWxlZnQ6IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1wb3Np dGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFs OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsi IGNsYXNzPSIiPkhlbGxvLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW4tcmlnaHQ6IDBjbTsgbWFyZ2luLWxlZnQ6IDBjbTsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3 aGl0ZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgd2lkb3dzOiAyOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtc3BhY2luZzogMHB4OyBiYWNrZ3JvdW5kLXBv c2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRp YWw7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyIgY2xhc3M9IiI+SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3Jh dGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkg cGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywNCiBhbmQgc29tZXRp bWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBw cm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZTwvc3Bhbj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IiIg Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcv dHJhYy93aWtpL1J0Z0RpciIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9Imljb24iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IHJnYig2OCwgMCwgMTM2KTsiIGNsYXNzPSIiPuKAizwvc3Bhbj48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDY4LCAwLCAxMzYpOyIgY2xh c3M9IiI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rp cjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1yaWdodDogMGNtOyBtYXJnaW4tbGVmdDogMGNtOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHdo aXRlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0OyB3aWRvd3M6IDI7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC1zcGFjaW5nOiAwcHg7IGJhY2tncm91bmQtcG9z aXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlh bDsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IiBjbGFzcz0iIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUg dXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQg Y29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50 cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbQ0KIHRocm91Z2gg ZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1yaWdodDogMGNtOyBtYXJnaW4tbGVmdDogMGNt OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtYWxpZ246IHN0YXJ0 OyB3aWRvd3M6IDI7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC1zcGFjaW5n OiAwcHg7IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1y ZXBlYXQ6IGluaXRpYWwgaW5pdGlhbDsiIGNsYXNzPSIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5Eb2N1bWVudDo8L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5kcmFmdC1pZXRmLW1wbHMtcmZjNDM3OWJpcy0wNjxiciBj bGFzcz0iIj4NClJldmlld2VyOiBEYW5pZWxlIENlY2NhcmVsbGk8L3NwYW4+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNz PSIiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpSZXZpZXcgRGF0ZTogMjcvMDkvMjAx NjxiciBjbGFzcz0iIj4NCklFVEYgTEMgRW5kIERhdGU6IGRhdGUtaWYta25vd248L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSIiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpJbnRlbmRlZCBTdGF0 dXM6IFN0YW5kYXJkIFRyYWNrPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGNtOyBtYXJnaW4tbGVmdDogMGNtOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtY29sb3I6 IHdoaXRlOyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQt cmVwZWF0OiBpbml0aWFsIGluaXRpYWw7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyIgY2xhc3M9IiI+V2hlbiBJIHNhdyB0aGF0IHRoZSBkb2N1 bWVudCB3YXMgb2Jzb2xldGluZyA0IHdlbGwga25vd24gYW5kIHdpZGVseSBkZXBsb3llZCBkb2N1 bWVudHMgSSB3YXMgc2NhcmVkLCBidXQgcmVhZGluZyB0aGUgc2hlcGhlcmQgd3JpdGUgdXAgaXQg c2VlbXMgdGhhdCB0aGUgZHJhZnRzIGdvdCBhIHdpZGUgY29uc2Vuc3VzIGluIHRoZSB3b3JraW5n IGdyb3VwLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw Y207IG1hcmdpbi1sZWZ0OiAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IGZvbnQtdmFyaWFu dC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgb3JwaGFuczog MjsgdGV4dC1hbGlnbjogc3RhcnQ7IHdpZG93czogMjsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB3b3JkLXNwYWNpbmc6IDBweDsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBp bml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyIgY2xhc3M9IiI+DQo8 c3Ryb25nIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyIgY2xhc3M9IiI+U3VtbWFyeTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSIiIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsiIGNsYXNzPSIiPk5vIGlzc3VlcyBmb3VuZC4gVGhpcyBkb2N1bWVudCBpcyByZWFkeSBm b3IgcHVibGljYXRpb24uPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1yaWdodDogMGNtOyBtYXJnaW4tbGVmdDogMGNtOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHdo aXRlOyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVw ZWF0OiBpbml0aWFsIGluaXRpYWw7IiBjbGFzcz0iIj4NCjxzdHJvbmcgY2xhc3M9IiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj5Db21tZW50czo8 L3NwYW4+PC9zdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwY207IG1hcmdpbi1sZWZ0OiAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7 IGJhY2tncm91bmQtcG9zaXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6 IGluaXRpYWwgaW5pdGlhbDsiIGNsYXNzPSIiPg0KPHN0cm9uZyBjbGFzcz0iIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsiIGNs YXNzPSIiPlRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGNvbXByZWhlbnNpYmxlLCBi dXQgSSBkaWRu4oCZdCBleHBlY3QgbGVzcyBmcm9tIHN1Y2ggYSBkcmVhbSB0ZWFtIG9mIGF1dGhv cnMuPC9zcGFuPjwvc3Ryb25nPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgZm9yIHRoZSBkb2N1bWVu dCBzdW1tYXJ5IGFib3ZlISA6LSk8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBh Z2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8cCBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwY207 IG1hcmdpbi1sZWZ0OiAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IGJhY2tncm91bmQtcG9z aXRpb246IGluaXRpYWwgaW5pdGlhbDsgYmFja2dyb3VuZC1yZXBlYXQ6IGluaXRpYWwgaW5pdGlh bDsiIGNsYXNzPSIiPg0KPHN0cm9uZyBjbGFzcz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvc3Ryb25nPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBjbTsgbWFyZ2luLWxlZnQ6IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3Vu ZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBp bml0aWFsOyIgY2xhc3M9IiI+DQo8c3Ryb25nIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IiBjbGFzcz0iIj5NYWpvciBJc3N1ZXM6PC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L3A+DQo8dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdpbi1ib3R0b206IDBjbTsiIGNsYXNz PSIiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJh Y2tncm91bmQtY29sb3I6IHdoaXRlOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+JnF1 b3Q7Tm8gbWFqb3IgaXNzdWVzIGZvdW5kLiZxdW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBjbTsgbWFyZ2luLWxlZnQ6IDBj bTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFy dDsgd2lkb3dzOiAyOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtc3BhY2lu ZzogMHB4OyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQt cmVwZWF0OiBpbml0aWFsIGluaXRpYWw7IiBjbGFzcz0iIj4NCjxzdHJvbmcgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGNsYXNzPSIiPk1pbm9yIElzc3Vlczo8L3NwYW4+ PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiIGNsYXNzPSIiPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIiBzdHlsZT0ibWFyZ2luLWJv dHRvbTogMGNtOyIgY2xhc3M9IiI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIiBjbGFzcz0iIj5CYWNrd2FyZCBjb21wYXRpYmlsaXR5LiBJIHdvdWxkIGV4cGVjdCB0byBz ZWUgYSBzZWN0aW9uIHdpdGggc29tZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzc3Vlcy4gUHJv YmFibHkgc2luY2UgYWxsIHRoZSBwcmV2aW91c2x5IGRlZmluZWQgbWV0aG9kcyBhbmQgZXh0ZW5z aW9ucyBhcmUgZGVwcmVjYXRlZCBubyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIGV4cGVjdGVk PyBJbiBhbnkgY2FzZSBpdA0KIGlzIHdvcnRoIG1lbnRpb25pbmcgaXQuPC9zcGFuPjwvbGk+PC91 bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5UaGlzIGlzIGEgZ29vZCBwb2ludC4gTXkgdGFrZSB3b3VsZCBiZSB0aGF0IGFz IHRoZSBkZXByZWNhdGVkIGVsZW1lbnRzIGFyZSBub3QgcGFydCBvZiB0aGUgc3BlY2lmaWNhdGlv biAodGhleSBhcmUgbW92ZWQgZG93biB0byBhIG5vbi1ub3JtYXRpdmUgYXBwZW5kaXggZm9yIGNv bXBsZXRlbmVzcyksIHRoZW4gYXMgeW91IHNheSB0aGVyZSBpcyBubyBiYWNrd2FyZHMgY29tcGF0 aWJpbGl0eS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRo aXMgZG9jdW1lbnQgZG9lcyBub3QgdmVyc2lvbiYjNDM7JiM0MzsgdGhlIHByb3RvY29sLjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+T25lIHRoaW5nIHdlIHNob3VsZCBk byBpcyBtYWtlIG1vcmUgY2xlYXIgdGhhdCBBcHBlbmRpeCBBIGlzIG5vbi1ub3JtYXRpdmUgZm9y IGFuIGltcGxlbWVudGF0aW9uLiBJIGNhbiBhZGQgYSBzZW50ZW5jZSB0aGVyZSwgaGVyZeKAmXMg b25lIHN1Z2dlc3Rpb24gZm9yIHRoZSBXRyB0byBjb25zaWRlcjo8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZsdDtzZWN0aW9uIHRpdGxlPSZxdW90 O0RlcHJlY2F0ZWQgVExWcyBhbmQgc3ViLVRMVnMgKE5vbi1ub3JtYXRpdmUpJnF1b3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZsdDt0Jmd0OzxiciBjbGFzcz0iIj4NClRoaXMgYXBwZW5kaXggZGVzY3Jp YmVzIGRlcHJlY2F0ZWQgZWxlbWVudHMsIHdoaWNoIGFyZSBub24tbm9ybWF0aXZlIGZvciBhbiBp bXBsZW1lbnRhdGlvbi48YnIgY2xhc3M9IiI+DQpUaGV5IGFyZSBpbmNsdWRlZCBpbiB0aGlzIGRv Y3VtZW50IGZvciBoaXN0b3JpY2FsIGFuZCBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzLjxiciBjbGFz cz0iIj4NCiZsdDsvdCZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9u MTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+DQo8dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdpbi1ib3R0b206IDBjbTsi IGNsYXNzPSIiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj4zLjIuOC4mbmJzcDsgRkVDIDEyOCBQc2V1ZG93aXJl IC0gSVB2NCAoRGVwcmVjYXRlZCkgdnMuIDMuMi45LiZuYnNwOyBGRUMgMTI4IFBzZXVkb3dpcmUg LSBJUHY0IChDdXJyZW50KS4gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhpcy4gSXMgdGhlcmUgYSBk ZXByZWNhdGVkIHZlcnNpb24gb2YgdGhlIEZFQyAxMjggUFcgYW5kIGEgY3VycmVudCBvbmU/IFdo ZXJlIGlzIHRoYXQgZGVwcmVjYXRlZD8gSSBkb27igJl0IHRoaW5rIHRoZXJlDQogaXMgdGhlIG5l ZWQgdG8gYWRkcmVzcyBib3RoIGJ1dCBqdXN0IHRoZSBjdXJyZW50IG9uZS48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvbGk+PC91bD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdj5ZZXMsIHRoaXMgaXMgY29taW5nIGZyb20gUkZDIDQzNzkgYmVjYXVzZSB0aGUgb3JpZ2lu YWxseSBkZWZpbmVkIEZFQyAxMjggd2l0aG91dCB0aGUgU2VuZGVy4oCZcyBJUCh2NCkgYWRkcmVz cywgYW5kIHdhcyBkZXByZWNhdGVkIGJlY2F1c2UgaXQgZG9lcyBub3QgdW5pdm9jYWxseSBpZGVu dGlmeSB0aGUgRkVDIOKAlCB0aGUg4oCcY3VycmVudOKAnSB3YXMgdGhlbiBhZGRlZCwgY29uc2Vx dWVudGx5LiBUaGlzIGRvY3VtZW50IGtlZXBzIHRoZSDigJxkZXByZWNhdGVk4oCdDQogdmVyc2lv buKAmXMgdGl0bGUgYW5kIElBTkEgbnVtYmVyLCBidXQgbW92ZWQgdGhlIGRlZmluaXRpb24gdG8g YW4gQXBwZW5kaXguPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0 eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHVsIHR5cGU9ImRpc2MiIHN0eWxl PSJtYXJnaW4tYm90dG9tOiAwY207IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvbGk+ PC91bD4NCjxwIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBjbTsgbWFyZ2luLWxlZnQ6IDBjbTsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBiYWNr Z3JvdW5kLWNvbG9yOiB3aGl0ZTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFs OyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyIgY2xhc3M9IiI+DQo8c3Ryb25n IGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyIgY2xh c3M9IiI+Tml0czo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3A+DQo8 dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdpbi1ib3R0b206IDBjbTsiIGNsYXNzPSIiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJhY2tncm91bmQt Y29sb3I6IHdoaXRlOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+SSB0aGluayB0aGlz IHNlbnRlbmNlIGNhbiBiZSByZW1vdmVkIGZyb20gdGhlIEFic3RyYWN0IOKAnFRoaXMgZG9jdW1l bnQgb2Jzb2xldGVzIFJGQ3MgNDM3OSwgNjQyNCwgNjgyOSwgYW5kIDc1Mzcu4oCdPC9zcGFuPjwv bGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KSXTigJlzIG5lY2Vzc2FyeSBhcyBwZXImbmJzcDs8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9pZC1pbmZvL2NoZWNrbGlzdC5odG1sI2FuY2hvcjYiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL2lkLWluZm8vY2hlY2tsaXN0Lmh0bWwjYW5jaG9yNjwvYT4mbmJz cDs8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2Vj dGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiPg0KPHVsIHR5cGU9ImRpc2MiIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAw Y207IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNs YXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+SW50cm9kdWN0aW9uOiAmbmJzcDvigJxBbiBp bXBvcnRhbnQgY29uc2lkZXJhdGlvbiBpbiB0aGlzIGRlc2lnbiBpcyB0aGF0IE1QTFMgZWNobyBy ZXF1ZXN0cyBmb2xsb3cgdGhlIHNhbWUgZGF0YSBwYXRoIHRoYXQgbm9ybWFsIE1QTFMgcGFja2V0 cyB3b3VsZCB0cmF2ZXJzZS7igJ0gSSBndWVzcyB0aGlzIGlzIG1hbmRhdGVkIGJ5IG90aGVyIGRv Y3VtZW50cywgcGxlYXNlIGFkZCBhIHJlZmVyZW5jZSwgb3RoZXJ3aXNlDQogdGhpcyBpcyBhIHN0 cm9uZyByZXF1aXJlbWVudCB0aGF0IG5lZWQgdG8gYmUgc3BlY2lmaWVkIHdpdGggUkZDMjExOSB0 ZXJtaW5vbG9neS48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KQSByZXF1aXJlbWVudCBkb2VzIG5vdCBuZWVkIHRvIGNvbWUgZnJvbSBhIGRpZmZlcmVudCAo ZS5nLiwg4oCcUmVxdWlyZW1lbnRz4oCdKSBkb2N1bWVudCBhbmQgSSB0aGluayB0aGF0IHRoaXMg ZG9jdW1lbnQgY2FuIGluY2x1ZGUgdGhhdCBkZXNpZ24gY3JpdGVyaWEgdXAgZnJvbnQsIGFzIGxv bmcgYXMgaXQgaXMgY2xlYXIgYW5kIHRyYW5zcGFyZW50LCB3aXRob3V0IGZpbmRpbmcgYSBjaXRh dGlvbi48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkkgYW0gaGVzaXRh bnQgdG8gYXJ0aWZpY2lhbGx5IGNoYXNlIGEgY2l0YXRpb24gdGhhdCB3YXMgbm90IGluIFJGQyA0 Mzc5LiBUaGF0IHNhaWQsIGlmIHRoZSBXRyB3YW50cyB3ZSBjYW4gZmluZCBzb21ldGhpbmcgYW5k IGFkZCBpdCAobGlrZSBmcm9tIDQzNzcgbWF5YmUpIOKAlCB0aG91Z2ggSSBwcm9iYWJseSB3b3Vs ZG7igJl0LzwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdv cmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdpbi1ib3R0 b206IDBjbTsiIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hp dGU7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBjbGFzcz0iIj5Nb3RpdmF0aW9uOiAoSUNNUCBlY2hv IHJlcXVlc3QgW1JGQzA3OTJdLiBJdOKAmXMgbmljZSB0byBoYXZlIGFsbCB0aGUgcmVmZXJlbmNl cyBpbiA0IGRpZ2l0cywgYnV0IEkgZ3Vlc3MgdGhlIDAgaXMgbm90IG5lZWRlZCBhdCB0aGlzIHRp bWUuPC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5XaGF0ZXZlciB4bWwycmZjIHJlbmRlcnMgOi0p IFRoZSBhbmNob3IgaW4gdGhlIGJpYnhtbCBpbmNsdWRlcyB0aGUg4oCcMOKAnS4mbmJzcDs8YSBo cmVmPSJodHRwczovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVm ZXJlbmNlLlJGQy4wNzkyLnhtbCIgY2xhc3M9IiI+aHR0cHM6Ly94bWwycmZjLnRvb2xzLmlldGYu b3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMDc5Mi54bWw8L2E+PC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlv bjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiPg0KPHVsIHR5cGU9ImRpc2MiIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAwY207 IiBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIGNsYXNz PSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+U2VjdGlvbiAyOiDigJxpcyBhIHB1cmUgUlNWUCBu b2RlIGFuZCBkb2Ugbm90IHJ1biBMRFDigJ0gcy9kb2VzL2RvZTwvc3Bhbj48L2xpPjwvdWw+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+Rml4ZWQuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGFu a3MgYWdhaW4hPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj7igJQgQ2Fy bG9zLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFn ZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjx1bCB0eXBlPSJkaXNjIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbTogMGNtOyIgY2xhc3M9IiI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7Ij4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQgMzZwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1jb2xvcjogd2hp dGU7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iIiBjbGFzcz0iIj5CUjxi ciBjbGFzcz0iIj4NCkRhbmllbGUmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_DB7AE56F937646F798A078843CB5901Cciscocom_--