From nobody Fri Oct 2 05:38:08 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103EC1B2B18; Fri, 2 Oct 2015 05:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogiObgV_zKTx; Fri, 2 Oct 2015 05:38:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EE11B2B15; Fri, 2 Oct 2015 05:38:00 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 4823019094D; Fri, 2 Oct 2015 14:37:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2181DC8012; Fri, 2 Oct 2015 14:37:58 +0200 (CEST) Received: from [10.193.71.204] (10.168.234.1) by OPEXCLILM22.corporate.adroot.infra.ftgroup (10.114.31.31) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 2 Oct 2015 14:37:57 +0200 From: To: Organization: Orange Message-ID: <369_1443789478_560E7AA6_369_5381_1_560E7AA5.8010008@orange.com> Date: Fri, 2 Oct 2015 14:37:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.168.234.1] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.2.120618 Archived-At: Cc: rtg-dir@ietf.org, trill@ietf.org Subject: [RTG-DIR] Routing Directorate QA Review of draft-ietf-trill-smart-endnodes-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 12:38:07 -0000 Hello, I have been selected as the Routing Directorate QA reviewer for this draft. For more information about the Routing Directorate, please see €‹http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir At this stage, the intend of the following is not to discuss the WG's decision about the I-D, but rather to help improving its content. Please not that I am deeply familiar with TRILL, but this was an interesting opportunity for me to browse a few RFCs from the WG and learn about the technology. Bottom line: I may raise some rookie's comments, feel free to educate me if appropriate. _Summary_ The I-D is well focused on a protocol specification, addressing a requirement with clear motivations. I must acknowledge a strong improvement from 01 to 02, both in terms of readability and specification. Beyond the list of minor issues below, I have one major concerns with 02. All the same, from where I stand, it does not look like a deep change and may not be that difficult to address. _Main Issue_ As far as I understand, the I-D now defines a new protocol among those to be carried within the RBridge Channel. This is consistent along sections 4.1 (encapsulation) and 8 (IANA allocations). What is now inconsistent is the use of IS-IS TLVs and sub-TLVs, probably because the former version seemed more IS-IS based. Several related problems: 1- The TRILL GENINFO mentioned in the I-D is an IS-IS TLV, the way it should be used in the Smart-Hello protocol is unclear. 2- The I-D is requesting a new APPsub-TLV from the GENINFO above, i.e., within the IS-IS registry. (a) A new protocol being defined, if the IS-IS registry is to be used, this needs to be clarified. (b) It is not clear either why the GENINFO top TLV is still useful since the information is not conveyed using IS-IS. 3- The I-D specification reuses yet another IS-IS TLV (242) to be included in "Smart-Hellos". While defining a TLV content aligned on an existing IS-IS TLV seems reasonable (the PCE WG faces a same situation with PCEP sometimes pointing to RSVP registry), this TLV must have its codepoint allocated as part of the "Smart-Hello" protocol, and values do not have to match. 4- Note also that IS-IS registry associates TLV with messages types (i.e., IIH, LSP, SNP, etc), that IIH does not support TLV 242 and that Smart-Hellos are not part of the list. This is likely to be solved as part of addressing 3-, once that TLV is allocated in a Smart-Hello registry. _Minor Issues_ ------ Global --- - The I-D is currently ST. For a protocol specification, there are too few occurrences of RFC 2119 keywords. Either the I-D is not really ST and the field should be updated, or the keywords, as well as RFC 2119 reference (which got dropped from 01 to 02) and introductory quote, should be included. - Capitalized 1st letters on "Smart Endnode" and "Smart-Hello" have been generalized, just a few ones were missed (e.g., in sections 2, 4.1, etc.). The choice is less clear on the "e/Edge RBridge" phrase: please make it consistent along the I-D. - Some character spacing should be fixed. ------ Header --- - All authors' first names have a trailing period to be dropped. ------ Section 2 --- - The section extensively use some of the acronyms only defined later. The terminology section should be moved before it. - s/solution proposed/solution defined/ - s/the below figure/the figure below/ - s/attached RB/attached RBridge/ - s/if there was no endnode entry/in the same situation/ - Figure 1: acronyms are enough, full phrases useless and heavy. - s/RB 1/RB1/ (on figure 1) - s/issues a Smart-Hello/issues a message called "Smart-Hello"/ - required acronym expansions (fine since terminology if moved before): "LSP" (the Routing area loves RFC 5513!), "E-L1FS FS LSP" ------ Section 3 --- - To be moved and extended (see above and below) - The "TRILL switch" phrase appears in various definitions: is it still needed beyond defining "RBridge"? I imagine it was required in early days of TRILL work, but now that has its own terminology, sticking to "[edge/transit] RBridge" looks clearer. Obviously, this should be enforced along the I-D, i.e., avoid "TRILL switch" in the remainder of the I-D. ------ Section 4 --- - s/smart end node/Smart Endnode/ - s/both for Smart-Hellos sent by Smart Endnodes and for Smart-Hellos sent by Edge RBridges/for Smart-Hellos sent by both Smart Endnodes and Edge RBridges/ - s/an 8-bit size and type field/an 8-bit size and 8-bit type fields./ - As pointed out as "main issue", RFC 6823 does not seem applicable here (though the idea may). - s/Endndoes/Endnodes/ - s/APPsub-TLv/APPsub-TLV/ - I am rather used to 32-bit-aligned TLV figures, but the display format used here does not harm. - I wonder why not choosing a fixed header format, using the larger size, i.e., 6-bit "RESV" and 24-bit "VLAN/FGL Data Label" in all cases. I see more trouble in handling 2 different sizes rather than carrying padded values. Moreover, the 2-bit RESV option may quickly become too small, since using one of these bits is already considered in section 6. - s/IS/node/ (Note that if the IS acronym was really to be used, it should join the terminology section.) ------ Section 5 --- - RFC 2119 keywords to be considered all along. - s/nicknamae/nickname/ - s/D either queries/SE1 either queries/ (if I understood well) - s/DRB/designated RBridge/ (used once, no need for the acronym) - In section 5.1, the very last sentence of the last paragraph should become penultimate: easier to read all expected behaviors first, and the crash/restart case only then. - The phrase "port with a [S]mart [N]ode", used a couple of times, read weird. "Port connected to a Smart Node" would ease parsing. - s/MAC (or Data Label)/MAC or Data Label/ - "would be dropped": an example of loose wording, RFC 2119 keywords are expected. - s/TRILL encapsulation/TRILL packet/ - "Normal endnodes" is not defined (implying smart ones are abnormal?), "non-smart endnodes" should be preferred and used each time. - s/decapsulate the frame/decapsulate the TRILL-encapsulated frame/ - s/two copies/two formats/ - s/A Smart Ennodes/a Smart Endnode/ - s/A normal (non-smart) endnode/A non-smart endnode/ - s/complexity/load/ - s/RECOMMENDED/recommended/ (That is deployment guideline, not protocol specification.) - "Another solution is..." Again, does not fit ST. ------ Section 6 --- - Supposing that the I-D is actually on ST, not less than 3 possible solutions are listed! If there is relevant work in progress, then point to it and stop. If a mechanism is really missing, then define only one. - s/RBridge RB1 and RB2/RBridges RB1 and RB2/ - s/multi- homing/multi-homing/ - S/RSV/RESV/ ------ Section 8 --- - Including a value is usually a bad idea at this stage. Please use "TBD" or start an early allocation procedure to have a stable value to mention. - As mentioned above: * Is it really an APPsub-TLV from IS-IS GENINFO that is needed? * IS-IS TLV242-like should be allocated as part of Smart-Hello. ------ Section 10 --- - Are those references all normative? I feel I have managed to understand the I-D without diving into all of them. (And beware of normative I-Ds...) ------ Best regards, Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Oct 7 11:51:25 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405391A1B72; Wed, 7 Oct 2015 11:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2oezkbQ-SeT; Wed, 7 Oct 2015 11:51:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5678D1A1BA3; Wed, 7 Oct 2015 11:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2360; q=dns/txt; s=iport; t=1444243862; x=1445453462; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=R4F0Z75oFiFn//5MjB2NZz8xSRa/9lu71oMI0lVhD8M=; b=LmUraYU4A9nM2SeXPqbrjLAIdbbpg+ttAl8Q1PWB7EleoyGnugwdEh5t ifpeOo03XHQs0j8XRnZVQQGM+DEwLdX+4SbHfc7LmdjkpZGMmaYUmqyY8 ri6E6bfn8brEb7ZioLSDB/o2RsjJOjV25YoWEfV0iZ3zjALwoBv1zUMB0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A9AwBCaBVW/5pdJa1egydUbga9QAENgVohgnKCCmYZgUY4FAEBAQEBAQGBCoQnAgQ6PxIBCBQiQicEAQ0FiC4NwkcBAQEBAQEEAQEBAQEBAQEahnMBhH2EYisJhCwFkk2DOAGFF4d/gVdIg3GDJIl6hFqDbx8BAUKEAnEBhmWBBgEBAQ X-IronPort-AV: E=Sophos;i="5.17,650,1437436800"; d="scan'208";a="195338288" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 07 Oct 2015 18:51:01 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t97Ip0ss029871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Oct 2015 18:51:00 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 7 Oct 2015 13:51:00 -0500 Received: from xhc-rcd-x07.cisco.com (173.37.183.81) by xch-aln-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 7 Oct 2015 13:51:00 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.102]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 13:50:59 -0500 From: "Alvaro Retana (aretana)" To: Mach Chen , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt Thread-Index: AQHRATEbU/y9hkSzOkmnsUfHiwepoA== Date: Wed, 7 Oct 2015 18:50:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.101.220.157] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-add-paths.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 18:51:24 -0000 On 5/7/15, 8:52 AM, "Mach Chen" wrote: Mach: Hi! I just published an update that should address your comments. Please take a look. Thanks! Alvaro. >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 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-idr-add-path-10.txt >Reviewer: Mach Chen >Review Date: 2015/05/07 >IETF LC End Date: Not known >Intended Status: Standards Track > >Summary: > This document is basically ready for publication, but has nits that >should be considered prior to publication. > >Comments:=20 > The document is well written and easy to read. >=20 >Major Issues:=20 > No major issues found. > >Minor Issues:=20 > No minor issues found. > >Nits: > >Abstract and Introduction > >s/In this document we propose/This document defines > > >Introduction > >s/"Send-update Process"/Send-update Process, to align with the usage as >in RFC4271. > >Section 4 > >"Send/Receive: > > This field indicates whether the sender is (a) able to receive > multiple paths from its peer (value 1), (b) able to send > multiple paths to its peer (value 2), or (c) both (value 3) for > the ." > >How about other values and what's the process when received value other >than 1, 2 and 3? > > >Section 5 > >OLD: >" A BGP speaker MUST follow the existing procedures in generating an > UPDATE message for a particular to a peer unless the >BGP..." > >NEW: >"A BGP speaker MUST follow the procedures defined in [RFC4271] in >generating an > UPDATE message for a particular to a peer unless the >BGP..." >" > >Best regards, >Mach From nobody Wed Oct 7 13:42:01 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CC31B305C; Wed, 7 Oct 2015 13:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVw2g0SFiTSv; Wed, 7 Oct 2015 13:41:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D970A1B3044; Wed, 7 Oct 2015 13:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25868; q=dns/txt; s=iport; t=1444250516; x=1445460116; h=from:to:cc:subject:date:message-id:mime-version; bh=qI1Oda1xRSNTZlJ/5IWyCyOkiXREOXDjegblUfCu4tk=; b=YInq4KLXWG4722OUAEa5NrkHFEGZquTdnIJNcL8b4p+zcQBkYw4sOTex R1tFvj5Whylhma63iw7Si3zkrRntHgq2XO8239fsWIpVPPlgnh3bxQYYH 6BuqyffIdCDpQxU4EWAxtzH88Ut2df3EDZ95v8f8CyaIuaQeH6ae4LYFR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A9AwDughVW/5JdJa1eglpNgUIGvUABDYFagxOCCmYZgUg4FAEBAQEBAQGBCoQnAgQtTBIBCDgHORQTBAENBRuIE8JpAQEBAQEBAQMBAQEBAQEBARqGcwGEfYUNhDUFkk2DOAGNFoFXkVeEWoNvHwEBQoIRHYFUcYZmgQYBAQE X-IronPort-AV: E=Sophos;i="5.17,650,1437436800"; d="scan'208,217";a="195447347" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 07 Oct 2015 20:41:56 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t97Kftc5008122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Oct 2015 20:41:56 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 7 Oct 2015 15:41:55 -0500 Received: from xhc-aln-x11.cisco.com (173.36.12.85) by xch-aln-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 7 Oct 2015 15:41:55 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.102]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 15:41:55 -0500 From: "Alvaro Retana (aretana)" To: Antoni Przygienda , "rtg-ads@tools.ietf.org" Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00 Thread-Index: AQHRAUCakKwTG6nI2kqnkUs5o9+gWQ== Date: Wed, 7 Oct 2015 20:41:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.102.16] Content-Type: multipart/alternative; boundary="_000_D1A513CBB846Caretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-route-oscillation-stop.all@tools.ietf.org" , "idr wg \(idr@ietf.org\)" Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 20:41:59 -0000 --_000_D1A513CBB846Caretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 5/26/15, 9:36 PM, "Antoni Przygienda" > wrote: [Author hat on.] Tony: Hi! It took me a while to get to this.. I just posted an update with clarifications that I think address your point= s. Responses to your comments inline. I'm just leaving in pieces where = we have additional comments. Thanks! Alvaro. Network Working Group D. Walton Internet-Draft Cumulus Networks Intended status: Standards Track A. Retana PRZ> I would like to question whether this is a standards Track document ? PRZ> It looks to me more BCP than Standards track. It relies on peers PRZ> supporting on optional capability and then it only SHOULDs the PRZ> intended behavior. In fact there is not a single normative MUST in PRZ> the whole document. I don't think you don=92t need MUSTs, or even any rfc2119 language for a do= cument to be a standard. Personally I don=92t think this is a BCP; it basically specifies how the ME= D oscillations can be resolved..so I think it should remain on the Standard= s Track. Having said that, if the chairs/AD have any guidance they want us to follow= , then we will. . . . These paths can be advertised using the mechanism described in ADD- PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. PRZ> I suggest to indicate in the document that all routers in AD MUST be PRZ> configured to behave consistently when comparing MEDs PRZ> (i.e. always-compare-med, missing-as-worst and so on need to be PRZ> consistent). PRZ> There seems to me a hidden assumption PRZ> in the document PRZ> albeit likely obvious for the skilled in the art that PRZ> always-compare-med is used here (and in fact the overall behavior PRZ> simulates deterministic-MED?) but IMO it must be mentioned what the PRZ> assumptions are. Especially for routers that want to the RRC but PRZ> do NOT support add-path e.g. PRZ> that they are sometimes employed to fix some of PRZ> those issues and need to be considered. >From the discussion in rfc3345 (where the oscillations are described), alwa= ys-compare-med is actually ruled out because it defeats the purpose of sett= ing the MED. Missing-as-worst is the default from rfc4271..so we=92re not = making any assumptions of what knobs are configured beyond the default. OTOH, yes, deterministic-MED is pretty much what is described in section 4 = (Advertise the Group Best Paths) as part of the solution. I added some clarification on assumptions. . . . 4. Advertise the Group Best Paths The term neighbor-AS for a route refers to the neighboring AS from which the route was received. The calculation of the neighbor-AS is specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of [RFC5065]. By definition the MED is comparable only among routes with the same neighbor-AS. PRZ> We all know this can be violated by vendor specific configs and PRZ> merits mentioning as reference to 4456 again since this is a very PRZ> 'practical deployment' It must be late..I=92m missing the reference to 4456 when talking about cha= nges in the default behavior. PRZ> targeted draft. In fact this draft should reference how two best PRZ> routes to same prefix via two different ASes (two group best paths PRZ> to same prefix) should be resolved or ECMP=92ed. I know that many implementations support that type of ECMP. However, that = is not an issue specific to this draft or even ADD-PATH. If we (the WG) ever wanted to document that internal behavior (similar to j= ust regular ECMP) it should be in a separate draft. There is no change to the resolution (finding the bestpath) of two group be= st paths. . . . PRZ> This needs specification WHAT is advertised to the peers not supporti= ng PRZ> add-path? if we follow today's behavior, it would be any PRZ> of the best-group paths broken on IGP metric. PRZ> I think it is worth mentioning that if ANY of the involved RRs does PRZ> not support add-path, the solution COULD loop again using IGP as tie-b= reaker PRZ> for routes from different ASes. PRZ> PRZ> Or is one of the restrictions this draft suggests PRZ> that all RRs MUST be PRZ> add-path capable ? Yes, we=92re assuming that the solution can be deployed because all routers= that need to support ADD-PATH. I think that assumption is clear in the tex= t as it mentions several times that the solution is based on it. We didn= =92t look at partial deployments. . . . --_000_D1A513CBB846Caretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8D2F5E071330CC478BA1CAC6436D1AEE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 5/26/15, 9:36 PM, "Antoni Przygienda" <antoni.przygienda@ericsson.com> w= rote:

[Author hat on.]

Tony:

Hi!

It took me a while to get to this..

I just posted an update with clarifications that I think address your = points.   Responses to your comments inline.   I'm just leaving i= n pieces where we have additional comments.

Thanks!

Alvaro.



Network Working G= roup            = ;            &n= bsp;            = ;     D. Walton

Internet-Draft     =             &nb= sp;            =             Cumulus = Networks

Intended status: Standards Track  =             &nb= sp;            =     A. Retana

 

PRZ> I would like to question w= hether this is a standards Track document ?

PRZ> It looks to me more BCP th= an Standards track. It relies on peers

PRZ> supporting on optional cap= ability and then it only SHOULDs the

PRZ> intended behavior. In fact= there is not a single normative MUST in

PRZ> the whole document.=


I don't think you don=92t need MUSTs, or even any rfc2119 language for= a document to be a standard.

Personally I don=92t think this is a BCP; it basically specifies how t= he MED oscillations can be resolved..so I think it should remain on the Sta= ndards Track.

Having said that, if the chairs/AD have any guidance they want us to f= ollow, then we will.

. . .

   These paths can be advertised u= sing the mechanism described in ADD-

   PATH [I-D.ietf-idr-add-paths] f= or advertising multiple paths.

 

PRZ> I suggest to indicate in t= he document that all routers in AD MUST be

PRZ> configured to behave consi= stently when comparing MEDs

PRZ> (i.e. always-compare-med, = missing-as-worst and so on need to be

PRZ> consistent).

PRZ> There seems to me a hidden= assumption

PRZ> in the document

PRZ> albeit likely obvious for = the skilled in the art that

PRZ> always-compare-med is used= here (and in fact the overall behavior

PRZ> simulates deterministic-ME= D?) but IMO it must be mentioned what the

PRZ> assumptions are. Especiall= y for routers that want to the RRC but

PRZ> do NOT support add-path e.= g.

PRZ> that they are sometimes em= ployed to fix some of

PRZ> those issues and need to b= e considered.

From the discussion in rfc3345 (where the oscillations are described),= always-compare-med is actually ruled out because it defeats the purpose of= setting the MED.  Missing-as-worst is the default from rfc4271..so we= =92re not making any assumptions of what knobs are configured beyond the default.

OTOH, yes, deterministic-MED is pretty much what is described in secti= on 4 (Advertise the Group Best Paths) as part of the solution.

I added some clarification on assumptions.

. . .

<= o:p>

 

4.  Advertise the Group Best Paths

 

   The term neighbor-AS for a rout= e refers to the neighboring AS from

   which the route was received.&n= bsp; The calculation of the neighbor-AS is

   specified in Sect. 9.1.2.2 of [= RFC4271], and Section 7.2 of

   [RFC5065].  By definition = the MED is comparable only among routes

   with the same neighbor-AS.

   

PRZ> We all know this can be vi= olated by vendor specific configs and=

PRZ> merits mentioning as refer= ence to 4456 again since this is a very

PRZ> 'practical deployment'

It must be late..I=92m missing the reference to 4456 when talking abou= t changes in the default behavior.

<= o:p>

PRZ> targeted draft. In fa= ct this draft should reference how two best

PRZ> routes to same prefix via = two different ASes (two group best paths

PRZ> to same prefix) should be = resolved or ECMP=92ed.  

I know that many implementations support that type of ECMP.  Howe= ver, that is not an issue specific to this draft or even ADD-PATH.

If we (the WG) ever wanted to document that internal behavior (similar= to just regular ECMP) it should be in a separate draft.

There is no change to the resolution (finding the bestpath) of two gro= up best paths.


. . .


 PRZ> This needs specification WHAT= is advertised to the peers not supporting

PRZ> add-path? if we follow tod= ay's behavior, it would be any

PRZ> of the best-group paths br= oken on IGP metric.

PRZ> I think it is worth mentio= ning that if ANY of the involved RRs does<= o:p>

PRZ> not support add-path, the = solution COULD loop again using IGP as tie-breaker

PRZ> for routes from different = ASes.

PRZ>

PRZ> Or is one of the restricti= ons this draft suggests

PRZ> that all RRs MUST be

PRZ> add-path capable ?<= /p>


Yes, we=92re assuming that the solution can be deployed because all ro= uters that need to support ADD-PATH. I think that assumption is clear in th= e text as it mentions several times that the solution is based on it.  = ;We didn=92t look at partial deployments.   

. . .
--_000_D1A513CBB846Caretanaciscocom_-- From nobody Wed Oct 7 14:04:07 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC31B30DE; Wed, 7 Oct 2015 14:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp9Hbd0bEMst; Wed, 7 Oct 2015 14:04:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59DC1B30DB; Wed, 7 Oct 2015 14:04:00 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-c9-561528db24cf Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3F.3C.32596.BD825165; Wed, 7 Oct 2015 16:14:51 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 17:03:59 -0400 From: Antoni Przygienda To: "Alvaro Retana (aretana)" , "rtg-ads@tools.ietf.org" Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00 Thread-Index: AQHRAUCakKwTG6nI2kqnkUs5o9+gWZ5ghEBw Date: Wed, 7 Oct 2015 21:03:58 +0000 Message-ID: <2E4BB27CAB87BF43B4207C0E55860F180EADF50C@eusaamb103.ericsson.se> References: 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_2E4BB27CAB87BF43B4207C0E55860F180EADF50Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonRPe2hmiYwZ2bVhZ/f25ltLh3ciG7 xavbz5gsns+ZyWKxYM1TdgdWjym/N7J6LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZe1Y/ YS+Y18xUcffJSsYGxm9PGbsYOTgkBEwkGs8qdzFyApliEhfurWfrYuTiEBI4yihx+sgiVghn GaPEtTuvGEGq2AQsJC5/e8oMYosIpEm87X8IVsQscI5RYvuC/ywgCWEBL4l1x7YwQhR5S8zr u8EOYRtJzJ9wFCzOIqAicWblNjCbV8BX4uqFP0wgtpCAnsSiz6vA5nAK6Esc2nMbLM4IdN73 U2vAbGYBcYlbT+YzQZwtILFkz3lmCFtU4uXjf6wQtpLEpKXnWCHq8yXOrVjIBrFLUOLkzCcs ExhFZyEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqRwSZG YAwek2DT3cG456XlIUYBDkYlHt4Hl4XDhFgTy4orcw8xSnOwKInz7l9yP1RIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QD4/R1SdUVUme/V+1pdA7Z/WRvnNifxmOqi1dcZWGXUJbfnOsVsuv7 /YvSF1RqXx65f1a37raL9oT+F6/WHZ9whnmvic/fww98RD7muL1wWOF6vzq2zV6Xy++Tpl3A /K37zn7knmoRsyy5NjxmQ8BkNZtrYpPNm/x09nMsle14uuHNpCMpSyKSS5RYijMSDbWYi4oT AbNeumCiAgAA Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-route-oscillation-stop.all@tools.ietf.org" , "idr wg \(idr@ietf.org\)" Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:04:06 -0000 --_000_2E4BB27CAB87BF43B4207C0E55860F180EADF50Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Uff, lost all the context after 5 months of having been on it. Lez take it= to the beer bar @ yokohama and you enlighten me. Some of the stuff you wri= te I agree with, some I lost context && need reconstruction. I only hope th= at meantime no one shipped an 'almost-never-not-compare-med' knob to compl= icate discussion further ;-) ... --- tony There are basically two types of people. People who accomplish things, and = people who claim to have accomplished things. The first group is less crowd= ed. ~~~ Mark Twain From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Wednesday, October 07, 2015 1:42 PM To: Antoni Przygienda; rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; draft-ietf-idr-route-oscillation-stop.all@tools.ietf.= org; idr wg (idr@ietf.org) Subject: Re: [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00 On 5/26/15, 9:36 PM, "Antoni Przygienda" > wrote: [Author hat on.] Tony: Hi! It took me a while to get to this.. I just posted an update with clarifications that I think address your point= s. Responses to your comments inline. I'm just leaving in pieces where = we have additional comments. Thanks! Alvaro. Network Working Group D. Walton Internet-Draft Cumulus Networks Intended status: Standards Track A. Retana PRZ> I would like to question whether this is a standards Track document ? PRZ> It looks to me more BCP than Standards track. It relies on peers PRZ> supporting on optional capability and then it only SHOULDs the PRZ> intended behavior. In fact there is not a single normative MUST in PRZ> the whole document. I don't think you don't need MUSTs, or even any rfc2119 language for a docu= ment to be a standard. Personally I don't think this is a BCP; it basically specifies how the MED = oscillations can be resolved..so I think it should remain on the Standards = Track. Having said that, if the chairs/AD have any guidance they want us to follow= , then we will. . . . These paths can be advertised using the mechanism described in ADD- PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. PRZ> I suggest to indicate in the document that all routers in AD MUST be PRZ> configured to behave consistently when comparing MEDs PRZ> (i.e. always-compare-med, missing-as-worst and so on need to be PRZ> consistent). PRZ> There seems to me a hidden assumption PRZ> in the document PRZ> albeit likely obvious for the skilled in the art that PRZ> always-compare-med is used here (and in fact the overall behavior PRZ> simulates deterministic-MED?) but IMO it must be mentioned what the PRZ> assumptions are. Especially for routers that want to the RRC but PRZ> do NOT support add-path e.g. PRZ> that they are sometimes employed to fix some of PRZ> those issues and need to be considered. >From the discussion in rfc3345 (where the oscillations are described), alwa= ys-compare-med is actually ruled out because it defeats the purpose of sett= ing the MED. Missing-as-worst is the default from rfc4271..so we're not ma= king any assumptions of what knobs are configured beyond the default. OTOH, yes, deterministic-MED is pretty much what is described in section 4 = (Advertise the Group Best Paths) as part of the solution. I added some clarification on assumptions. . . . 4. Advertise the Group Best Paths The term neighbor-AS for a route refers to the neighboring AS from which the route was received. The calculation of the neighbor-AS is specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of [RFC5065]. By definition the MED is comparable only among routes with the same neighbor-AS. PRZ> We all know this can be violated by vendor specific configs and PRZ> merits mentioning as reference to 4456 again since this is a very PRZ> 'practical deployment' It must be late..I'm missing the reference to 4456 when talking about chang= es in the default behavior. PRZ> targeted draft. In fact this draft should reference how two best PRZ> routes to same prefix via two different ASes (two group best paths PRZ> to same prefix) should be resolved or ECMP'ed. I know that many implementations support that type of ECMP. However, that = is not an issue specific to this draft or even ADD-PATH. If we (the WG) ever wanted to document that internal behavior (similar to j= ust regular ECMP) it should be in a separate draft. There is no change to the resolution (finding the bestpath) of two group be= st paths. . . . PRZ> This needs specification WHAT is advertised to the peers not supporti= ng PRZ> add-path? if we follow today's behavior, it would be any PRZ> of the best-group paths broken on IGP metric. PRZ> I think it is worth mentioning that if ANY of the involved RRs does PRZ> not support add-path, the solution COULD loop again using IGP as tie-b= reaker PRZ> for routes from different ASes. PRZ> PRZ> Or is one of the restrictions this draft suggests PRZ> that all RRs MUST be PRZ> add-path capable ? Yes, we're assuming that the solution can be deployed because all routers t= hat need to support ADD-PATH. I think that assumption is clear in the text = as it mentions several times that the solution is based on it. We didn't l= ook at partial deployments. . . . --_000_2E4BB27CAB87BF43B4207C0E55860F180EADF50Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Uff, lost all the cont= ext after 5 months of having been on it.  Lez take it to the beer bar = @ yokohama and you enlighten me. Some of the stuff you write I agree with, = some I lost context && need reconstruction. I only hope that meantime no one shipped an ‘almost-never-not-compar= e-med’  knob to complicate discussion further ;-) …

 

--- tony

 

 

From: Alvaro R= etana (aretana) [mailto:aretana@cisco.com]
Sent: Wednesday, October 07, 2015 1:42 PM
To: Antoni Przygienda; rtg-ads@tools.ietf.org
Cc: rtg-dir@ietf.org; draft-ietf-idr-route-oscillation-stop.all@tool= s.ietf.org; idr wg (idr@ietf.org)
Subject: Re: [Idr] RtgDir review: draft-ietf-idr-route-oscillation-s= top-00

 

On 5/26= /15, 9:36 PM, "Antoni Przygienda" <antoni.przygienda@ericsson.com> wrote:

&n= bsp;

[Author= hat on.]

&n= bsp;

Tony:

&n= bsp;

Hi!

&n= bsp;

It took= me a while to get to this..

&n= bsp;

I just = posted an update with clarifications that I think address your points. &nbs= p; Responses to your comments inline.   I'm just leaving in pieces whe= re we have additional comments.

&n= bsp;

Thanks!=

&n= bsp;

Alvaro.=

&n= bsp;

&n= bsp;

&n= bsp;

Network= Working Group          &= nbsp;           &nbs= p;            &= nbsp;      D. Walton

Internet-Draft   =             &nb= sp;            =             &nb= sp; Cumulus Networks

Intended status: Standards Track=             &nb= sp;            =       A. Retana=

 

PRZ> I would like to question w= hether this is a standards Track document ?

PRZ> It looks to me more BCP th= an Standards track. It relies on peers

PRZ> supporting on optional cap= ability and then it only SHOULDs the

PRZ> intended behavior. In fact= there is not a single normative MUST in

PRZ> the whole document.=

&n= bsp;

I don't= think you don’t need MUSTs, or even any rfc2119 language for a docum= ent to be a standard.

&n= bsp;

Persona= lly I don’t think this is a BCP; it basically specifies how the MED o= scillations can be resolved..so I think it should remain on the Standards T= rack.

&n= bsp;

Having = said that, if the chairs/AD have any guidance they want us to follow, then = we will.

&n= bsp;

. . .

   These paths can be = advertised using the mechanism described in ADD-

   PATH [I-D.ietf-idr-= add-paths] for advertising multiple paths.

 

PRZ> I suggest to indicate in t= he document that all routers in AD MUST be

PRZ> configured to behave consi= stently when comparing MEDs

PRZ> (i.e. always-compare-med, = missing-as-worst and so on need to be

PRZ> consistent).

PRZ> There seems to me a hidden= assumption

PRZ> in the document

PRZ> albeit likely obvious for = the skilled in the art that

PRZ> always-compare-med is used= here (and in fact the overall behavior

PRZ> simulates deterministic-ME= D?) but IMO it must be mentioned what the

PRZ> assumptions are. Especiall= y for routers that want to the RRC but

PRZ> do NOT support add-path e.= g.

PRZ> that they are sometimes em= ployed to fix some of

PRZ> those issues and need to b= e considered.

&n= bsp;

From th= e discussion in rfc3345 (where the oscillations are described), always-comp= are-med is actually ruled out because it defeats the purpose of setting the= MED.  Missing-as-worst is the default from rfc4271..so we’re not making any assumptions of what knobs are = configured beyond the default.

&n= bsp;

OTOH, y= es, deterministic-MED is pretty much what is described in section 4 (Advert= ise the Group Best Paths) as part of the solution.

&n= bsp;

I added= some clarification on assumptions.

&n= bsp;

. . .

&n= bsp;

 

4.  Advertise the Group Bes= t Paths

 

   The term neighbor-A= S for a route refers to the neighboring AS from

   which the route was= received.  The calculation of the neighbor-AS is

   specified in Sect. = 9.1.2.2 of [RFC4271], and Section 7.2 of=

   [RFC5065].  By= definition the MED is comparable only among routes

   with the same neigh= bor-AS.

   

PRZ> We all know this can be vi= olated by vendor specific configs and

PRZ> merits mentioning as refer= ence to 4456 again since this is a very

PRZ> 'practical deployment'

&n= bsp;

It must= be late..I’m missing the reference to 4456 when talking about change= s in the default behavior.

&n= bsp;

PRZ> targeted draft. In fa= ct this draft should reference how two best

PRZ> routes to same prefix via = two different ASes (two group best paths

PRZ> to same prefix) should be = resolved or ECMP’ed.  

&n= bsp;

I know = that many implementations support that type of ECMP.  However, that is= not an issue specific to this draft or even ADD-PATH.

&n= bsp;

If we (= the WG) ever wanted to document that internal behavior (similar to just reg= ular ECMP) it should be in a separate draft.

&n= bsp;

There i= s no change to the resolution (finding the bestpath) of two group best path= s.

&n= bsp;

&n= bsp;

. . .

 

 PRZ> This needs specificatio= n WHAT is advertised to the peers not supporting

PRZ> add-path? if we follow tod= ay's behavior, it would be any

PRZ> of the best-group paths br= oken on IGP metric.

PRZ> I think it is worth mentio= ning that if ANY of the involved RRs does

PRZ> not support add-path, the = solution COULD loop again using IGP as tie-breaker

PRZ> for routes from different = ASes.

PRZ>

PRZ> Or is one of the restricti= ons this draft suggests

PRZ> that all RRs MUST be

PRZ> add-path capable ?<= span style=3D"color:black">

&n= bsp;

Yes, we= ’re assuming that the solution can be deployed because all routers th= at need to support ADD-PATH. I think that assumption is clear in the text a= s it mentions several times that the solution is based on it.  We didn’t look at partial deployments.  &= nbsp;

&n= bsp;

. . .

--_000_2E4BB27CAB87BF43B4207C0E55860F180EADF50Ceusaamb103erics_-- From nobody Wed Oct 7 14:09:50 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6BF1B30DA; Wed, 7 Oct 2015 14:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rxBXMbDTtcX; Wed, 7 Oct 2015 14:09:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7751B30C9; Wed, 7 Oct 2015 14:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3334; q=dns/txt; s=iport; t=1444252187; x=1445461787; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=U/fglCHx4ziilrvaXNosjEKnclTl8r9irSuskD1v11Y=; b=JOPjGhBeABOQFlx4jSVxPacVpg1x3HD5tjT9b8B6d5rFwo5V3GoKJtcv wORd/S8ILGaj2gknvWHGa7cYm2+UtgXJD+hYD9K6kMh2gSN0E+CBoYyb1 QClMHdE2qg+1tl08RwVQyudR5aWvl6r95AafHqpISIgJzbzTo0FLgVIT+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8CAC9iBVW/5NdJa1eglpNgUIGvyiDE4IKZhkCgUY8EAEBAQEBAQGBCoQnAQEEeRACAQgEOwcyFBECBAENBYguwmABAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnMBhH2FDQeELgEEkk2DOAGNFpt3OCuEAnGGZoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,651,1437436800"; d="scan'208,217";a="194986746" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 07 Oct 2015 21:09:47 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t97L9khV020828 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Oct 2015 21:09:46 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 7 Oct 2015 16:09:45 -0500 Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-rcd-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 7 Oct 2015 16:09:45 -0500 Received: from xmb-aln-x15.cisco.com ([169.254.9.102]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 16:09:45 -0500 From: "Alvaro Retana (aretana)" To: Antoni Przygienda , "rtg-ads@tools.ietf.org" Thread-Topic: [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00 Thread-Index: AQHRAUCakKwTG6nI2kqnkUs5o9+gWZ5ghEBwgAAS9wA= Date: Wed, 7 Oct 2015 21:09:44 +0000 Message-ID: References: <2E4BB27CAB87BF43B4207C0E55860F180EADF50C@eusaamb103.ericsson.se> In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F180EADF50C@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.18] Content-Type: multipart/alternative; boundary="_000_D23B01EFD8D89aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "draft-ietf-idr-route-oscillation-stop.all@tools.ietf.org" , "idr wg \(idr@ietf.org\)" Subject: Re: [RTG-DIR] [Idr] RtgDir review: draft-ietf-idr-route-oscillation-stop-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2015 21:09:48 -0000 --_000_D23B01EFD8D89aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 10/7/15, 5:03 PM, "Antoni Przygienda" > wrote: Uff, lost all the context after 5 months of having been on it. Lez take it= to the beer bar @ yokohama and you enlighten me. You got it! Some of the stuff you write I agree with, some I lost context && need recon= struction. I only hope that meantime no one shipped an =91almost-never-not-= compare-med=92 knob to complicate discussion further ;-) Nope..just the new 'randomly-compare-med', which is of course the new defau= lt. Alvaro. --_000_D23B01EFD8D89aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <451DFE5A863A3F40896DCE53EBC5F646@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 10/7/15, 5:03 PM, "Antoni Przygienda" <antoni.przygienda@ericsson.com> w= rote:

Uff, lost all the context after 5 months of having been on it.  Lez take i= t to the beer bar @ yokohama and you enlighten me.

You got it!   

Some of the stuff you write I agree with, some I lost context && need r= econstruction. I only hope that meantime no one shipped an =91almost-never-= not-compare-med=92  knob to complicate discussion further ;-) 

Nope..just the new 'randomly-compare-med', which is of course the new = default.

Alvaro.
--_000_D23B01EFD8D89aretanaciscocom_-- From nobody Fri Oct 9 05:45:24 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1994F1B32EA; Fri, 9 Oct 2015 05:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azHOL2LT00xA; Fri, 9 Oct 2015 05:45:19 -0700 (PDT) Received: from mgw030.noc.ntt.com (mgw030.noc.ntt.com [210.160.55.3]) by ietfa.amsl.com (Postfix) with ESMTP id 05B391B32EF; Fri, 9 Oct 2015 05:45:19 -0700 (PDT) Received: from c0042i0.coe.ntt.com (c0042i0.nc.agilit-hosting.com [10.18.161.11]) by mgw030.noc.ntt.com (NTT Com MailSV) with ESMTP id 57FC41C58B8B; Fri, 9 Oct 2015 21:45:18 +0900 (JST) Received: from C0037I0.coe.ntt.com (10.18.160.41) by c0042i0.coe.ntt.com (10.18.161.11) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 9 Oct 2015 21:45:11 +0900 Received: from C0010I0.coe.ntt.com ([169.254.2.215]) by C0037I0.coe.ntt.com ([10.18.160.41]) with mapi id 14.03.0181.006; Fri, 9 Oct 2015 21:45:18 +0900 From: Tomonori Takeda To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-teas-rsvp-te-domain-subobjects-03 Thread-Index: AdECjPgdQtd7ksYYTNyEIozGoU0BLA== Date: Fri, 9 Oct 2015 12:45:17 +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@tools.ietf.org x-ccmail-original-cc: rtg-dir@ietf.org, draft-ietf-teas-rsvp-te-domain-subobjects@ietf.org, teas@ietf.org x-originating-ip: [10.18.84.148] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "teas@ietf.org" , "draft-ietf-teas-rsvp-te-domain-subobjects@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-teas-rsvp-te-domain-subobjects-03 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 12:45: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. 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-teas-rsvp-te-domain-subobjects-03.txt Reviewer: Tomonori Takeda Review Date: 9 October 2015 IETF LC End Date: Not known Intended Status: Experimental Summary: No issues found. This document is ready for publication. Comments: This document intends to be an Experimetal RFC, adding new subobjects for IGP areas and 4-byte AS numbers for ERO, XRO or EXRS in RSVP-TE. There are several example use cases in Appendix. I am not confident whether there is a real value to define new subobjects for IGP areas, but new subobjects does not break anything, thus I think it is fine to go forward. Major Issues: None Minor Issues: None Nits: None Thanks, Tomonori Takeda From nobody Mon Oct 12 01:55:59 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323881A89EB; Mon, 12 Oct 2015 01:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKmVtZT6Zvc0; Mon, 12 Oct 2015 01:55:54 -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 6974D1A89B3; Mon, 12 Oct 2015 01:55:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCK91917; Mon, 12 Oct 2015 08:55:51 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 12 Oct 2015 09:55:51 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.229]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Mon, 12 Oct 2015 16:55:43 +0800 From: Mach Chen To: "Alvaro Retana (aretana)" , "rtg-ads@tools.ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt Thread-Index: AQHRATEbU/y9hkSzOkmnsUfHiwepoJ5nlH2Q Date: Mon, 12 Oct 2015 08:55:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "idr@ietf.org" , "draft-ietf-idr-add-paths.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 08:55:56 -0000 Hi Alvaro, I have reviewed the latest version, it addresses my comments. Thanks, Mach > -----Original Message----- > From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] > Sent: Thursday, October 08, 2015 2:51 AM > To: Mach Chen; rtg-ads@tools.ietf.org > Cc: idr@ietf.org; draft-ietf-idr-add-paths.all@tools.ietf.org; rtg-dir@ie= tf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-add-path-10.txt >=20 > On 5/7/15, 8:52 AM, "Mach Chen" wrote: >=20 > >=20 > Mach: >=20 > Hi! >=20 > I just published an update that should address your comments. Please tak= e a > look. >=20 > Thanks! >=20 > Alvaro. >=20 > >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-idr-add-path-10.txt > >Reviewer: Mach Chen > >Review Date: 2015/05/07 > >IETF LC End Date: Not known > >Intended Status: Standards Track > > > >Summary: > > This document is basically ready for publication, but has nits that > >should be considered prior to publication. > > > >Comments: > > The document is well written and easy to read. > > > >Major Issues: > > No major issues found. > > > >Minor Issues: > > No minor issues found. > > > >Nits: > > > >Abstract and Introduction > > > >s/In this document we propose/This document defines > > > > > >Introduction > > > >s/"Send-update Process"/Send-update Process, to align with the usage as > >in RFC4271. > > > >Section 4 > > > >"Send/Receive: > > > > This field indicates whether the sender is (a) able to receive > > multiple paths from its peer (value 1), (b) able to send > > multiple paths to its peer (value 2), or (c) both (value 3) for > > the ." > > > >How about other values and what's the process when received value other > >than 1, 2 and 3? > > > > > >Section 5 > > > >OLD: > >" A BGP speaker MUST follow the existing procedures in generating an > > UPDATE message for a particular to a peer unless the > >BGP..." > > > >NEW: > >"A BGP speaker MUST follow the procedures defined in [RFC4271] in > >generating an > > UPDATE message for a particular to a peer unless the > >BGP..." > >" > > > >Best regards, > >Mach From nobody Thu Oct 15 12:22:04 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0639D1A00A0; Thu, 15 Oct 2015 12:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.61 X-Spam-Level: X-Spam-Status: No, score=-11.61 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, J_CHICKENPOX_82=0.6, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJmNkgzF14IT; Thu, 15 Oct 2015 12:21:55 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21031A009E; Thu, 15 Oct 2015 12:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70186; q=dns/txt; s=iport; t=1444936914; x=1446146514; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZYbJNCGmPdAYsWwKVBdWpJ5CHLVmnf9xLc+9DXLC7K8=; b=hUO8E6l9QF2PydGAujAZ8OUkgrMsVK7SxsBOIRtzKoC3laZ8RTzg0qp6 /Nz2ojW4b6FjU0CD6qjwmNir1wndiMln1vhvbIQ0pKVS89NG1xsKytCTY buLBcUOkEvbdtYPKL7bzHMSkmkEy6+spHaGOl5ofKQ5RqliBsJF6gUi70 A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DJAgCm/B9W/4ENJK1UCoJZTVRuBr03DoFWAxcBC4UxSgKBOjgUAQEBAQEBAX8LhCYBAQEDAQEBARcJSAIBCwUJAgIBCBQEIAEGAwICFhELFBEBAQQOBQ4LiA0IDbAQkzUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBIZyghCCboQqBgsBQAwBBAeCaTGBFAWHOYcGhAGDXQGCTYFhaoJwhRKBWEiDcoMkd5FiAREOAUOCER2BVXEBhCY6gQYBAQE X-IronPort-AV: E=Sophos;i="5.17,687,1437436800"; d="asc'?scan'208,217";a="37934743" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 15 Oct 2015 19:21:33 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t9FJLXwn027871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2015 19:21:33 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 15 Oct 2015 14:21:18 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Thu, 15 Oct 2015 14:21:18 -0500 From: "Carlos Pignataro (cpignata)" To: "Alexander.Vainshtein@ecitele.com" Thread-Topic: [L2tpext] RTG-DIR review: draft-ietf-l2tpext-keyed-ipv6-tunnel-05 Thread-Index: AdDyOEeydLWLDBZKSmuscJKgoKVIHgVcFG0A Date: Thu, 15 Oct 2015 19:21:18 +0000 Message-ID: <8FEFEEB2-0AC5-4C81-9727-AB9D49DB1913@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.62] Content-Type: multipart/signed; boundary="Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "l2tpext@ietf.org" , "draft-ietf-l2tpext-keyed-ipv6-tunnel.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "Mark Townsley \(townsley\)" , "Stewart Bryant \(stbryant\)" Subject: Re: [RTG-DIR] [L2tpext] RTG-DIR review: draft-ietf-l2tpext-keyed-ipv6-tunnel-05 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 19:22:01 -0000 --Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A Content-Type: multipart/alternative; boundary="Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447" --Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Deborah, Authors of draft-ietf-l2tpext-keyed-ipv6-tunnel, Following up on this email =E2=80=94 who has the token on the next step? Authors, should you answer Sasha=E2=80=99s review? Thanks, =E2=80=94 Carlos. > On Sep 18, 2015, at 1:34 PM, Alexander.Vainshtein@ecitele.com wrote: >=20 > 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. >=20 > Document: draft-ietf-l2tpext-keyed-ipv6-tunnel-05txt > Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein > Review Date: 18-Sep-15 > IETF LC End Date: Not Known > Intended Status: Proposed Standard >=20 > Caveat: > I am not an IPv6 expert and this can be the reason for some of my = concerns about the draft. > My experience with L2TPv3 is also outdated. So I=E2=80=99d like to ask = the Routing ADs to take my comments with a big grain of salt. >=20 > Summary: > I have one significant concern about this document and recommend that = the Routing ADs discuss these issues further with the authors. I also = have several minor concerns about the document that I think should be = resolved before publication, and I have find a couple of nits. >=20 > Comments: > As I see it, the draft is built around three key ideas: > 1. IPv6 addresses, due to their unlimited availability, can be = used to identify attachment circuits (or VSI forwarders) of L2TPv3 = sessions (and not just tunnel endpoints as in RFC 3931). > 2. With IPv6 addresses used for identifying L2 circuits or VSI) = to be connected by L2TPv3 PWs, L2TPv3 Session ID processing in the data = plane can be bypassed. I can guess that this really simplifies data = plane handling and that this was the prime driver for the technology the = draft defines, but this is just a guess. > 3. L2TPv3 sessions identified by IPv6 addresses can be used to = provide operator-managed services that neither need nor use L2TPv3 = control plane. The control plane functionality is moved to an external = management entity that can access both endpoints of the service, sets = the service up and continuously intervenes in its operation until it = tears down the service. >=20 > The term =E2=80=9Ckeyed IPv6 tunnel=E2=80=9D refers to an L2TPv3 = session that bypasses Session ID processing and relies on IPv6 addresses = of its endpoints. Depending on the nature of emulated Ethernet service, = these IPv6 addresses are used to identify either L2 attachment circuits = for P2P services or Virtual Switching Instances (VSI) for MP2MP = services. >=20 > Since L2TPv3 control plane is by design left out of scope of the = draft, it mainly deals with the data plane. Additional information about = the management plane aspects can be found in the YANG Data Model = draft. >=20 > The draft is not easy to read and understand (at least to me), mainly = because pieces of important information are often distributed throughout = the text. One example illustrating this complaint: > =C2=B7 The first sentence in Section 2 states that =E2=80=9CStat= ic local configuration creates a one-to-one mapping between the = access-side L2 attachment circuit and the IP address used in the = network-side IPv6 encapsulation. The L2TPv3 Control Plane defined in = RFC3931 is not used=E2=80=9D. This suggests(at least to me) that the = management plane is involved just in setting up and tearing down a keyed = IPv6 tunnel =E2=80=93 similar to how static PWs over MPLS PSN are = operated. >=20 > =C2=B7 The catch comes with the last sentence of Section 3: = =E2=80=9CCookie values SHOULD be changed periodically=E2=80=9D thus = indicating that continuous intervention of the management entity is = expected for the entire life cycle of the service =E2=80=93 something = that strongly smells of Lifecycle Service Orchestration (LSO) to me, = even if the term is never mentioned. >=20 > In the process of preparing this review I have sent my comments to the = authors, to Carlos (the draft shepherd) and to Mark (who is listed as a = contributing author). I have received very useful feedback from them = that has helped me to understand both the draft and the nature of our = disagreements. I would like to thank Giles, Rayner, Carlos and Mark for = a very useful discussion, even if we did not reach an agreement on some = of the points yet. >=20 > Major Issue: > Specification of encapsulation of Ethernet frames in Section 4 of the = draft is incomplete and, to some extent, contradictory: > 1. L2TPv3 L2-specific sublayer defined in RFC 3931 is not = mentioned anywhere in the text. > 2. As the draft borrows encapsulation of Ethernet frames from RFC = 4719, one could expect that its usage is OPTIONAL (same as in RFC 4719) > 3. On the other hand, L2-specific sublayer does not appear in the = diagram depicting the encapsulation on page 5, so one could easily = assume that it cannot be used with keyed IPv6 tunnels >=20 > 4. To add to this confusion, the draft mentions ability to use = VCCV in a keyed IPv6 tunnel (Section 6, last para), and references RFC = 5085. But this RFC, in Section 6.1 states that =E2=80=9CIn order to = carry VCCV messages within an L2TPv3 session data packet, the PW MUST be = established such that an L2-Specific Sublayer (L2SS) that defines the = V-bit is present=E2=80=9D >=20 > =46rom my POV the authors must clearly and unequivocally specify = whether L2-specific sublayer can or cannot be used in keyed IPv6 = tunnels. If they decide that it cannot be used, the references to VCCV = must be removed from the draft. >=20 > I believe that this gap is acknowledged by the document shepherd and = by one of the authors. >=20 > Minor Issues: >=20 > 1. The draft does not explain the motivation for replacing the = mechanism defined in RFC 4791 (which, AFAIK, was supposed to work = equally well over IPv4 and IPv6). I can guess that bypassing processing = of Session ID simplifies the data plane processing, but this is just my = guess. Some text explaining the benefits of keyed IPv6 tunnels in = comparison with RFC 4719 would be most helpful IMO. > 2. To the best of my understanding, the technology defined in the = draft heavily depends on availability of an external management entity = that not only sets up and tears down the service (as is common with = services that uses statically configured PWs, say, in MPLS-TP), but also = intervenes in the operation of the service during its entire life cycle. = However, the authors do not spell out their expectations from such an = entity, the only exception being the need to periodically change the = cookie values in a coordinated manner. I do not expect the draft to = provide a detailed specification of such an entity, but I think that = both the implementers and operators planning to deploy this technology = would benefit from some additional information. In particular, the = following aspects of behavior of the service that uses keyed IPv6 = tunnels could be of special interest: > a. What happens to a P2P service that uses a keyed IPv6 tunnel = to connect two Ethernet L2 circuits if failure of one of these circuits = is detected (e.g., using Ethernet service CFM between the Down MEP at = the tunnel endpoint and a matching MEP in the CE as defined in Section = 6, the first bullet on page 8)? Is transmission across the IPv6 PSN at = the other endpoint expected to be throttled by the management entity? > b. The possibility to use an anycast address for identification = of a keyed IPv6 tunnel endpoint is mentioned twice in the draft - in = Section 2, 3rd para and in Section 4, first bullet on page 6. What = happens if an anycast address assigned to one of the endpoints of a = keyed IPv6 tunnel moves across the network? Is the management entity = expected to handle these transitions, say, by de-activating the former = endpoint associated with an anycast address and activating the new one? > c. Is the management entity expected to emulate the PW = redundancy mechanisms (defined in RFC 67180 and RFC 6870 for PWs over an = MPLS PSN and in RFC 5641 for the PWs using L2TPv3? It should be noted = that, in the case of MPLS PWs, PW redundancy switchover does not require = involvement of a management entity even for statically configured PWs. = Instead, static PW status messages (RFC 6478) are used > d. The draft mentions the possibility to use keyed IPv6 tunnels = to connect VSI participating in an MP2MP Ethernet service (even if the = term VSI is never used). To me this implies that local FIB in each of = the VSI connected over keyed IPv6 tunnels would use MAC learning to = populate its local FIB. In order to speed up convergence of such = services following various external events, RFC 4672 introduces a = dedicated mechanism for MAC withdrawal, and the PALS WG currently holds = a WG item extending this functionality for VPLS services that use static = PWs. Is the management entity expected to provide similar functionality = as well? (It should be noted that MAC withdrawal mechanisms have been = defined as OPTIONAL in RFC 4762, but, AFAIK, they are widely implemented = and deployed in the field). > 3. The draft mentions (in many places) that it expects consistent = configuration of the endpoints of a keyed IPv6 tunnel. However, the = draft (probably following a similar omission in RFC 4719) never mentions = whether the management entity should prevent setting up a keyed IPv6 = tunnel between a pair of endpoints with different MTU of L2 circuits. = (This is a clear-cut requirement in RFC 4448 for Ethernet PWs over an = MPLS PSN, and a parallel requirement for PWs over L2TPv3 can be found in = RFC 4667). A short statement and a reference to RFC 4667 (missing in = RFC 4719) would suffice IMO, > 4. As mentioned before, the draft de-facto assigns IPv6 addresses = to access-side L2 circuits that are not IP interfaces (the draft uses = the term =E2=80=9Cmapping=E2=80=9D, but I do not see any difference). = The draft RECOMMENDS (in para 2 of Section 2) that =E2=80=9Clocal IPv6 = addresses identifying L2TPv3 tunnels are assigned from dedicated = subnets used only for such tunnel endpoints=E2=80=9D. =46rom my POV this = requirement is vague and the readers could benefit from clarification of = associated issues. Again, I do not expect a detailed specification, but = I would like to see the some answers to the following na=C3=AFve = questions: > a. Is an IPv6 address identifying an endpoint of a keyed IPv6 = tunnel that is associated with a L2 circuit expected to remain reachable = if the L2 circuit to which it is associated fails? > b. Are addresses (or subnets) used for identification of = endpoints of keyed IPv6 tunnels expected to be exposed beyond the = boundaries of the management domain controlled by the above-mentioned = management entity? Could they appear in the public Internet routing = tables? > 5. The draft says (Section 2, 3rd para) that =E2=80=9CCertain = deployment scenarios may require using a single IPv6 address (typically = a globally routable unicast or anycast address assigned to a virtual = interface) to identify a tunnel endpoint for multiple IPv6 L2TPv3 = tunnels. For such cases the tunnel encapsulating device identifies = each tunnel by a unique combination of local and remote IPv6 = addresses=E2=80=9D. =46rom my POV the readers would benefit from the = following clarifications: > a. What exactly =E2=80=9Ca globally routable address=E2=80=9D = means in this context? > b. How, from the point of view of network reachability, are IPv6 = addresses used in this scenario different from IPv6 addresses used to = identify L2 circuits in other deployment scenarios? > c. Since the text mentions identification of the tunnel by an = =E2=80=9Cencapsulation device=E2=80=9D, how is the tunnel identified by = the decapsulating device? At least from the POV of MAC learning in the = case of keyed IPv6 tunnels connecting VSI, identification of the tunnel = by the decapsulating device seems more relevant to me > d. How should the device know whether a specific keyed IPv6 = tunnel can be identified by just one IPv6 address or by a =E2=80=9Ca = unique combination of local and remote IPv6 addresses=E2=80=9D? > 6. As I have mentioned above, some details pertaining to the = management functionality associated with keyed IPv6 tunnels are defined = in another L2TPEXT WG draft, but this draft is not mentioned in the = draft I am reviewing. I think that an Informative reference to this = draft would be very much in place in this one. > 7. I wonder whether an Informative reference to a long = (13-Jan-1999 according to the Datatracker) expired draft = of a = concluded WG in the last sentence on page 3 has any value for the = reader. If the ideas of this draft have found their way to some RFC, it = should be used as a reference instead; otherwise I believe that this = reference cold be safely removed. >=20 > Some of the issues I have raised could be addressed in a suitable = Applicability Statement section, but there are clearly other ways to = handle them. >=20 > Nits: > I (or, rather, my spellchecker) has found two typos: > =C2=B7 Section 2, para 2: s/endponts/endpoints/ > =C2=B7 Section 5, para 3 on page 7: = s/Fragmention/Fragmentation/ >=20 > Regards, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com = >=20 > _______________________________________________ > L2tpext mailing list > L2tpext@ietf.org > https://www.ietf.org/mailman/listinfo/l2tpext = --Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Deborah, Authors of draft-ietf-l2tpext-keyed-ipv6-tunnel,

Following up on this = email =E2=80=94 who has the token on the next step?

Authors, should you = answer Sasha=E2=80=99s review?

Thanks,

=E2=80=94 Carlos.


On = Sep 18, 2015, at 1:34 PM, Alexander.Vainshtein@ecitele.com wrote:

Hello,
I have been selected as the Routing Directorate reviewer for = this draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir=
Although these comments are = primarily for the use of the Routing ADs, it would be helpful if you = could consider them along with any other IETF Last Call comments that = you receive, and strive to resolve them through discussion or by = updating the draft.
 
Document: draft-ietf-l2tpext-keyed-ipv6= -tunnel-05txt 
Reviewer: Alexander (=E2=80=9CSasha=E2=80=9D) Vainshtein
Review Date: 18-Sep-15
IETF LC End Date: Not = Known 
Intended Status: Proposed Standard
 
Caveat:

I am = not an IPv6 expert and this can be the reason for some of my concerns = about the draft.

My = experience with L2TPv3 is also outdated. So I=E2=80=99d like to ask the = Routing ADs to take my comments with a big grain of salt.

 
Summary: 

I have one significant concern about this document and = recommend that the Routing ADs discuss these issues further with the = authors. I also have several minor concerns about the document that I = think should be resolved before publication, and I have find a couple of = nits.

 
Comments:

As I = see it, the draft is built around three key ideas:

1.      IPv6 addresses, due to their unlimited availability, can be = used to identify attachment circuits (or VSI forwarders)  of L2TPv3 = sessions (and not just tunnel endpoints as in RFC 3931). 

2.      With IPv6 addresses used for identifying L2 circuits or VSI) = to be connected by L2TPv3 PWs, L2TPv3 Session ID processing in the data = plane can be bypassed. I can guess that this really simplifies data = plane handling and that this was the prime driver for the technology the = draft defines, but this is just a guess.

3.      L2TPv3 sessions identified by IPv6 addresses can be used to = provide operator-managed services that neither need nor use L2TPv3 = control plane. The control plane functionality is moved to an external = management entity that can access both endpoints of the service, sets = the service up and continuously intervenes in its operation until it = tears down the service.

 

The term =E2=80=9Ckeyed IPv6 tunnel=E2=80=9D refers to = an L2TPv3 session that bypasses Session ID processing and relies on IPv6 = addresses of its endpoints. Depending on the nature of emulated Ethernet = service, these IPv6 addresses are used to identify either L2 attachment = circuits for P2P services or Virtual Switching Instances (VSI) for MP2MP = services.

 

Since L2TPv3 control plane is by design left out of = scope of the draft, it mainly deals with the data plane. Additional = information about the management plane aspects can be found in the YANG Data Model draft.

 

The = draft is not easy to read and understand (at least to me), mainly = because pieces of important information are often distributed throughout = the text. One example illustrating this = complaint:

=C2=B7         The first sentence in Section 2 states that =E2=80=9CStatic local configuration creates a one-to-one mapping = between the  access-side L2 attachment circuit and the IP address = used in the network-side IPv6 encapsulation.  The L2TPv3 Control = Plane defined in RFC3931 is not used=E2=80=9D. This suggests(at least to me) that the = management plane is involved just in setting up and tearing down a keyed = IPv6 tunnel =E2=80=93 similar to how static PWs over MPLS PSN are = operated.

=C2=B7         The catch comes with the last sentence of Section 3: = =E2=80=9CCookie values SHOULD be changed = periodically=E2=80=9D = thus indicating that continuous intervention of the management entity is = expected for the entire life cycle of the service =E2=80=93 something = that strongly smells of Lifecycle Service Orchestration (LSO) to me, = even if the term is never mentioned.

In the process of preparing this review I have sent my = comments to the authors, to Carlos (the draft shepherd) and to Mark (who = is listed as a contributing author). I have received very useful = feedback  from them that has helped me to understand both the draft = and the nature of our disagreements.  I would like to thank Giles, = Rayner, Carlos and Mark for a very useful discussion, even if we did not = reach an agreement on some of the points yet.

 

Major Issue:

Specification of encapsulation of Ethernet frames in Section = 4 of the draft is incomplete and, to some extent, contradictory:

1.      L2TPv3 L2-specific sublayer  defined in RFC 3931 is not = mentioned anywhere in the text.

2.      As the draft borrows encapsulation of Ethernet frames from = RFC 4719, one could expect that its usage is OPTIONAL (same as in RFC = 4719)

3.      On the other hand, L2-specific sublayer does not appear in = the diagram depicting the encapsulation on page 5, so one could easily = assume that it cannot be used with keyed IPv6 tunnels

4.      To add to this confusion, the draft mentions ability to use = VCCV in a keyed IPv6 tunnel (Section 6, last para), and references RFC = 5085. But this RFC, in Section 6.1 states that =E2=80=9CIn = order to carry VCCV messages within an L2TPv3 session data packet, the = PW MUST be established such that an L2-Specific Sublayer (L2SS) that = defines the V-bit is present=E2=80=9D

=46rom = my POV the authors must clearly and unequivocally specify whether = L2-specific sublayer can or cannot be used in keyed IPv6 tunnels. If = they decide that it cannot be used, the references to VCCV must be = removed from the draft. 

I believe that this gap is acknowledged by the = document shepherd and by one of the authors.

          &nb= sp;    Minor = Issues:

1.      The draft does not explain the motivation for replacing the = mechanism defined in RFC 4791 (which, AFAIK, was supposed to work = equally well over IPv4 and IPv6). I can guess that bypassing processing = of Session ID  simplifies the data plane processing, but this is = just my guess. Some text explaining the benefits of keyed IPv6 tunnels = in comparison with RFC 4719 would be most helpful IMO.

2.      To the best = of my understanding, the technology defined in the draft heavily depends = on availability of an external management entity that not only sets up = and tears down the service (as is common with services that uses = statically configured PWs, say, in MPLS-TP), but also intervenes in the = operation of the service during its entire life cycle. However, the = authors do not spell out their expectations from such an entity, the = only exception being the need to periodically change the cookie values = in a coordinated manner. I do not expect the draft to provide a detailed = specification of such an entity, but I think that both the implementers = and operators planning to deploy this technology would benefit from some = additional information. In particular, the following aspects of behavior = of the service that uses keyed IPv6 tunnels could be of special = interest:

a.       What happens = to a P2P service that uses a keyed IPv6 tunnel to connect two Ethernet = L2 circuits if failure of one of these circuits is detected (e.g., using = Ethernet service CFM  between the Down MEP at the tunnel endpoint = and a matching MEP in the CE as defined in Section 6, the first bullet = on page 8)? Is transmission across the IPv6 PSN at the other endpoint = expected to be throttled by the management entity? 

b.      The = possibility to use an anycast address for identification of a keyed IPv6 = tunnel endpoint is mentioned twice in the draft - in Section 2, 3rd para= and in Section 4, first bullet on page 6. What happens if an anycast = address assigned to one of the endpoints of a keyed IPv6 tunnel moves = across the network? Is the management entity expected to handle these = transitions, say, by de-activating the former endpoint associated with = an anycast address and activating the new one?

c.       Is the = management entity expected to emulate the PW redundancy mechanisms = (defined in RFC 67180 and RFC 6870 for PWs over an MPLS PSN and in RFC = 5641 for the PWs using L2TPv3? It should be noted that, in the case of = MPLS PWs, PW redundancy switchover does not require involvement of a = management entity even for statically configured PWs. Instead, static PW = status messages (RFC 6478) are used

d.      The draft = mentions the possibility to use keyed IPv6 tunnels to connect VSI = participating in an MP2MP Ethernet service (even if the term VSI is = never used). To me this implies that local FIB in each of the VSI = connected over keyed IPv6 tunnels would use MAC learning to populate its = local FIB. In order to speed up convergence of such services following = various external events, RFC 4672 introduces a dedicated mechanism for = MAC withdrawal, and the PALS WG currently holds a WG item extending this = functionality for VPLS services that use static PWs. Is the management = entity expected to provide similar functionality as well? (It should be = noted that MAC withdrawal mechanisms have been defined as OPTIONAL in = RFC 4762, but, AFAIK, they are widely implemented and deployed in the = field).

3.      The draft = mentions (in many places) that it expects consistent configuration of = the endpoints of a keyed IPv6 tunnel. However, the draft (probably = following a similar omission in RFC 4719) never mentions whether the = management entity should prevent setting up a keyed IPv6 tunnel between = a pair of endpoints with different MTU of L2 circuits. (This is a = clear-cut requirement in RFC 4448 for Ethernet PWs over an MPLS PSN, and = a parallel requirement for PWs over L2TPv3 can be found in RFC = 4667).  A short statement and a reference to RFC 4667 (missing in = RFC 4719) would suffice IMO,

4.      As mentioned before, the draft = de-facto assigns IPv6 addresses to access-side L2 circuits that are not = IP interfaces (the draft uses the term =E2=80=9Cmapping=E2=80=9D, but I = do not see any difference). The draft RECOMMENDS (in para 2 of Section = 2) that =E2=80=9Clocal = IPv6 addresses identifying L2TPv3 tunnels are assigned from  = dedicated subnets used only for such tunnel endpoints=E2=80=9D. =46rom my POV this = requirement is vague and the readers could benefit from clarification of = associated issues. Again, I do not expect a detailed specification, but = I would like to see the some answers to the following na=C3=AFve = questions:

a.       Is  an IPv6 address identifying an endpoint of a keyed = IPv6 tunnel that is associated with a L2 circuit expected to remain = reachable if the L2 circuit to which it is associated fails?

b.      Are addresses (or subnets) used for identification of = endpoints of keyed IPv6 tunnels expected to be exposed beyond the = boundaries of the management domain controlled by the above-mentioned = management entity? Could they appear in the public Internet routing = tables?

5.      The draft says (Section 2, 3rd para) that =E2=80=9CCertain deployment scenarios may require using a single IPv6 = address (typically a globally routable unicast or anycast address = assigned to a virtual interface) to identify a tunnel endpoint for = multiple IPv6 L2TPv3 tunnels.  For such cases the tunnel = encapsulating device  identifies each tunnel by a unique = combination of local and remote    IPv6 = addresses=E2=80=9D. = =46rom my POV the readers would benefit from the following = clarifications:

a.       What exactly =E2=80=9Ca globally routable = address=E2=80=9D = means in this context?

b.      How, from the point of view of network reachability, are IPv6 = addresses used in this scenario different from IPv6 addresses used to = identify L2 circuits in other deployment scenarios?

c.       Since the text mentions identification of the tunnel by an = =E2=80=9Cencapsulation device=E2=80=9D, how is the tunnel identified by the = decapsulating device? At least from the POV of MAC learning in the case = of keyed IPv6 tunnels connecting VSI, identification of the tunnel by = the decapsulating device seems more relevant to me

d.      How should the device  know whether a specific keyed = IPv6 tunnel can be identified by just one IPv6 address or by a = =E2=80=9Ca unique combination of local and remote =    IPv6 addresses=E2=80=9D?

6.      As I have mentioned above, some details pertaining to the = management functionality associated with keyed IPv6 tunnels are defined = in another L2TPEXT WG draft, but this draft is not mentioned in the = draft I am reviewing.  I think that an Informative reference to this draft = would be very much in place in this one.

7.      I wonder = whether an Informative reference to a long (13-Jan-1999 according to the = Datatracker) expired draft of = a concluded WG in the last sentence on page 3 has any value for the = reader. If the ideas of this draft have found their way to some RFC, it = should be used as a reference instead; otherwise I believe that this = reference cold be safely removed.

 

Some of the issues I have raised could be addressed in = a suitable Applicability Statement section, but there are clearly other = ways to handle them.

 
Nits:

I (or, rather, my spellchecker) has = found two typos:

=C2=B7         Section 2, para 2: s/endponts/endpoints/

=C2=B7         Section 5, para 3 on page = 7:  s/Fragmention/Fragmentation/

 
Regards,
Sasha
 
Office: +972-39266302
Cell:      = +972-549266302
 
_______________________________________________
L2tpext mailing = list
L2tpext@ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext

= --Apple-Mail=_DBE8B59F-FA1C-48F5-B118-DBDDE5E21447-- --Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWH/y4AAoJEIXgpQGOZny9Dr0P/jWDlDk69LGFIjfouiHv8xYh Tunbn5O2NRcYSXdv8nda1s+L5Wuik5ErYYQcQc0zq6zkhi1dEnfGe3rJsVNLxp/6 5ssjSQxqRSvGHrUrhSIhzLV+3yJyqjuod2AwAla6k6i//oCB/0q6gRwgLDKQ0wFK hN0Yp/8k0OJUOssrcpQw3PnwzI/eXxGdMSalerYssxTbv8Ley8/j+YZ0CWpT0s9B 7sG3qY3UGyw8pIMnhSKklLtnJ6utjsEoQ6TkR+S4uprfwPc6TcECzSaM/1MJ49lP jUFA/bu5w5ZIzOM7uxwuxJNYAedFgt6aeREjOCCC/MchpbXxVkAJ+eiLOsLZaJIT zkjVtrUBBwyKxPX88qRLbtsnHPaWoN0LaQsxWrpMKgg0pWL4wxhI36lFQHoOhYjy 0NCDTf5yqcStdgZDTABhPJogAJjAjJoRQsJA5QqCP8IYKRkqJSSvqWt77K4wmTpZ Ck+I8Z+P4ae3vx6eo7zp8iiKhmlodJBDlFVmgoD+vZLzIxws/VmlVfGMMd270rXI kN/Cc55iHcF5jTxb3iGUC3VPIuMLJALw4qzf2B9n7IyAKoHLc8a10zo1TsrHMnba KVq6F9FdB3R+HoPkHgDqGd9vmLirUB3Ivto3YoivSEudxislnCZwAtIVGKZLbgAb MLaKY7/6hac2S5b5hBze =Vz9k -----END PGP SIGNATURE----- --Apple-Mail=_FC96179C-5889-4BCE-A40F-144631B9849A-- From nobody Mon Oct 19 12:46:22 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271671A8AFA for ; Mon, 19 Oct 2015 12:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG3ydL_lAaDM for ; Mon, 19 Oct 2015 12:45:56 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (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 5E7621A6EF9 for ; Mon, 19 Oct 2015 12:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=4ay0yP3YyeNbxy46lmhZ4NOKZzhgWn7jLFiPfNb1dzI=; b=1hejM+luEaYdLL4LwqwpTzv03U543p1cnkWEcokdAO9xSfgE31B25Dx13/uhb8otRt4q7+OO5UGDo F1Ef42dyp1073anEGFSlGj8C8vyO8F+4ZwHxvxVNdm/RHDGzLqZhtlyVMHSg4rASxMbWlu95k2ifkJ 7PVCkGB2+YfxsCgs= Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Tue, 20 Oct 2015 05:45:50 +1000 (AEST) Received: from [192.168.82.191] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 20 Oct 2015 05:48:18 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Geoff Huston In-Reply-To: <56251236.9020108@inex.ie> Date: Tue, 20 Oct 2015 06:45:43 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <632F50F6-1F42-452E-944C-BC0A2CD2A682@apnic.net> References: <84B60265-9CB4-46C7-8326-E24A451CFBDC@apnic.net> <56251236.9020108@inex.ie> To: X-Mailer: Apple Mail (2.3094) Archived-At: Cc: rtg-dir@ietf.org, Nick Hilliard , draft-ietf-idr-ix-bgp-route-server@tools.ietf.org, "idr@ietf.org wg" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-idr-ix-bgp-route-server X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:45:59 -0000 I can conform that draft -09 addresses the concerns I raised in my = review, and I have no further concerns with this document - as far as I am concerned it=E2=80=99= s good to go! thanks, Geoff > On 20 Oct 2015, at 2:54 AM, Nick Hilliard wrote: >=20 > Geoff, ADs, >=20 > thanks for your review. >=20 > =46rom a technical correctness point of view, the text in section 2.3 = is > indeed "speculative". It's not possible within the scope of this = document > to change rfc6774 to be standards track or to get the add-paths draft = to > rfc stage. You're also correct that there is no formal description = about > how to handle multiple loc-ribs, even though there are several of > production implementations which do this. >=20 > Having said that, the authors would feel uncomfortable about writing a > document about how to approach an RS implementation without flagging = path > hiding and its potential workarounds. Production IXPs tend to view = this as > being an important part of RS implementations. >=20 > We've taken your comments on board and have explicitly noted that = section > 2.3 and all its subsections are informational only. The rfc2119 = language > in this section has also been toned down to remove any implication = that the > section could be interpreted as normative. >=20 > Separate to this, the wording has been changed for the minor issue. >=20 > Draft -09 has now been published; hopefully this will address the = concerns > you raised. >=20 > Nick >=20 > On 08/09/2015 00:59, Geoff Huston 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-idr-ix-bgp-route-server-08.txt >> Reviewer: Geoff Huston >> Review Date: 8 September 2015 >> IETF LC End Date:=20 >> Intended Status: Standards Track >>=20 >>=20 >> Summary:=20 >>=20 >> I have significant concerns about this document and recommend that = the=20 >> Routing ADs discuss these issues further with the authors. >>=20 >> Comments: >>=20 >> The document is clear, and easily read.=20 >>=20 >> Sections 2.1 and 2.2 are consistent with a Standards Track = specification >> document >>=20 >> Section 2.3 appears to be more speculative in nature and the text is >> consistent with an informational document, but not necessarily = consistent >> with a Standards Track specification. >>=20 >> Major Issues: >>=20 >> 2.3. Per-Client Policy Control in Multilateral Interconnection >>=20 >> I am having a lot of difficulty understanding the role of this = section in >> a standards track document. The section describes a problem of a = route >> server exercising unilateral route policy selection, and thereby >> occluding potential routes from the route server's clients. >>=20 >> The document then describes three potential approaches for = addressing >> this issue: >>=20 >> 2.3.2.1 Multiple Route Server RIBS >>=20 >> Is there a reference for this approach? If not, then is this text = intended >> to be the reference specification for multi-RIBs?=20 >>=20 >> I'm not entirely comfortable with this section as part of a = Standards >> Track specification given the lack of a clear specification of this >> routing behaviour. The informal two paragraph description of the = intended >> behaviour seems to me to be inconsistent with a standards track >> specification. >>=20 >> 2.3.2.2.1. Diverse BGP Path Approach >>=20 >> This references RFC6774, an Informational document. >>=20 >> Given that the document subsequently states that "A route server = SHOULD >> implement one of the methods described in Section 2.3.2 to allow >> per-client routing policy control without "path hiding"." then I am = very >> surprised to see RFC6774 listed as Informative rather than = Normative. It >> should be Normative. But then as its Informational, this becomes a >> downref in this document which the authors need to address. >>=20 >> 2.3.2.2.2. BGP ADD-PATH Approach >>=20 >> This references [I-D.ietf-idr-add-paths]. >>=20 >> Same comment as above. >>=20 >>=20 >> The Standards track document is saying that a Route Server SHOULD = implement >> one of three approaches where one is unreferenced, one is = informataional and >> one is still a draft. >>=20 >> I think this is a major impediment to the document's progress as a = Standards >> Track document. >>=20 >>=20 >> Minor Issues: >>=20 >> 1. Introduction, Second Paragraph: >>=20 >> The unilateral assertion about scaling is perhaps over-doing it. The = text >> should add a qualifier such as "in large exchanges" or "in some >> circumstances" so that the sentence is not interpreted as a = universal >> condition, but one that arises as the number of peer sessions = increases >> at an exchange >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 > Network Ability Ltd. | Chief Technical Officer | Tel: +353 1 5313339 > 52 Lower Sandwith St | INEX - Internet Neutral | > Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie From nobody Wed Oct 21 09:02:47 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1554C1A9084; Wed, 21 Oct 2015 09:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oFiGq908JNO; Wed, 21 Oct 2015 09:02:44 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8DF1A6FE5; Wed, 21 Oct 2015 09:02:44 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so98267043wic.1; Wed, 21 Oct 2015 09:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=p3voGnCj2pJYtRvzcL4m3wj0r7hH0gsRwf3NFHZ5zA4=; b=hs+SlgpLjLh+tdFYQ6a8Vu98ciYR7NiNWzZqiRa6TVGUc0tozuxzyty8ayY4BB65m3 Dj67KAiLetKZckyHxSiNXlPr/JBE7sX67nHW1bIbd9vPPLlzkxx4adRIugululQuXPAz AQXhvV6nbjqPjSMRlhaJiGToyKnWt7EvH5WaVikDgBSN2Tbekzjwzu7yiPT7aUnRUpam 4wnOfiDW3Zc1ntZ4nkisCywiaP3BnFex0AN4OL2sAVLbUna/SaVi0Xkc5bs91Eb/kaNt pNvrl5NkOSRJrqWc70nIbiRzsAeXPJJHMbMGfYwSKnH4cWbB6jsYhumT1jVVuXfv7SvK UDkQ== MIME-Version: 1.0 X-Received: by 10.194.90.169 with SMTP id bx9mr13103886wjb.1.1445443362760; Wed, 21 Oct 2015 09:02:42 -0700 (PDT) Received: by 10.194.152.234 with HTTP; Wed, 21 Oct 2015 09:02:42 -0700 (PDT) Date: Thu, 22 Oct 2015 00:02:42 +0800 Message-ID: From: Lizhong Jin To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7bfd0df82e30c805229f822c Archived-At: Cc: rtg-dir@ietf.org, homenet@ietf.org, draft-ietf-homenet-dncp@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-homenet-dncp-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 16:02:46 -0000 --047d7bfd0df82e30c805229f822c 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-homenet-dncp-11 .txt Reviewer: Lizhong Jin Review Date: Oct, 21st IETF LC End Date: Intended Status: Standards Track *Summary:* I have some minor concerns about this document that I think should be resolved before publication. *Comments:* - This draft provides an abstraction protocol specification, instead of defining a real protocol. If authors could provide a realistic standardi= zed protocol based on this draft, that would be more convincing. - My biggest concern of this draft is the hash based network state update. The draft does not describe the case of hash collision. If the h= ash collision happens, then the network state will fail to update, which wil= l be a severe problem. Although it maybe low probability of hash collision= if we have longer hash length, but the question is, does the network could accept one collision? *Nits:* - Some acronyms need to expand when first use, e.g., A_NC_I, CA, SHSP. Regards Lizhong --047d7bfd0df82e30c805229f822c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

I have b= een selected as the Routing Directorate reviewer for this draft. The Routin= g Directorate seeks to review all routing or routing-related drafts as they= pass through IETF last call and IESG review, and sometimes on special requ= est. The purpose of the review is to provide assistance to the Routing ADs.= For more information about the Routing Directorate, please see=C2=A0=E2=80=8Bhttp://trac.tools.ietf.= org/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:=C2=A0draft-ietf-homenet-dncp-11.txt=C2=A0
Reviewer: L= izhong Jin=C2=A0
Review Date: Oct, 21st=C2=A0
IETF LC End Date: =C2= =A0
Intended Status: Standards Track

Summ= ary:=C2=A0
I have some minor concerns about this document that = I think should be resolved before publication.

Comments:

  • This draft provides an ab= straction protocol specification, instead of defining a real protocol. If a= uthors could provide a realistic standardized protocol based on this draft,= that would be more convincing.
  • My biggest concern of this draf= t is the hash based network state update. The draft does not describe the c= ase of hash collision. If the hash collision happens, then the network stat= e will fail to update, which will be a severe problem. Although it maybe lo= w probability of hash collision if we have longer hash length, but the ques= tion is, does the network could accept one collision?

Nits:

  • Some=C2=A0acrony= ms need to expand when first use, e.g.,=C2=A0A_NC_I, CA,=C2=A0SHSP.

Regards
Lizhong

--047d7bfd0df82e30c805229f822c-- From nobody Wed Oct 21 09:16:58 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2451B2A04; Wed, 21 Oct 2015 09:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PEqRYsJ_yKz; Wed, 21 Oct 2015 09:16:54 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117E61B29FB; Wed, 21 Oct 2015 09:16:54 -0700 (PDT) Received: by obctp1 with SMTP id tp1so18672895obc.2; Wed, 21 Oct 2015 09:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WALApJ1+j2NVJnwPPbyjvWiNwlj0J154AzvccD9fRuU=; b=pJaHH5pBLA8CVFXnEQeDbrDuT0xCsUPP2cVNhopJITCyr5uOaRvYBvvGG1ZZ+U3nFL oV682Bt8DnXa/VwZ7I7ZinovAuAcouiEicMjaC2MZEF+Tbpz2OWNH0kW5RgnCLtjKvWO bfK+gGCmcfscC3C1pvobXQne8nHICCucRn8lrFkVfmG1D8eaIKoJfVP16AJflWcFTDSX PYit/9IaFkXWhvovWuIsiWJCVJWSlfENg42R/mT2/BsCVsFX5UaZ7w0WNqSAt9sKUukp rr22ZmoSQNNOw/wSCLVy0s7diVPcOerbhvGjpwa7gMgF5ZXpsm6gsEzaV74rv82kZ3sk 6ipA== MIME-Version: 1.0 X-Received: by 10.182.214.37 with SMTP id nx5mr6757378obc.13.1445444213425; Wed, 21 Oct 2015 09:16:53 -0700 (PDT) Received: by 10.60.121.74 with HTTP; Wed, 21 Oct 2015 09:16:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Oct 2015 12:16:53 -0400 Message-ID: From: Alia Atlas To: Lizhong Jin Content-Type: multipart/alternative; boundary=e89a8ff1ccb4e24b5f05229fb481 Archived-At: Cc: "rtg-dir@ietf.org" , HOMENET , draft-ietf-homenet-dncp@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-homenet-dncp-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 16:16:56 -0000 --e89a8ff1ccb4e24b5f05229fb481 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Lizhong, Thank you very much for doing this review on such short notice. I have updated my ballot to request that the draft include a section about considerations for selecting a hash function and the bits to use - so as to make the probability of a network hash or node hash collision low enough to be acceptable. Thanks, Alia On Wed, Oct 21, 2015 at 12:02 PM, Lizhong Jin 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-homenet-dncp-11 > .txt > Reviewer: Lizhong Jin > Review Date: Oct, 21st > IETF LC End Date: > Intended Status: Standards Track > > *Summary:* > I have some minor concerns about this document that I think should be > resolved before publication. > > *Comments:* > > - This draft provides an abstraction protocol specification, instead > of defining a real protocol. If authors could provide a realistic > standardized protocol based on this draft, that would be more convinci= ng. > - My biggest concern of this draft is the hash based network state > update. The draft does not describe the case of hash collision. If the= hash > collision happens, then the network state will fail to update, which w= ill > be a severe problem. Although it maybe low probability of hash collisi= on if > we have longer hash length, but the question is, does the network coul= d > accept one collision? > > *Nits:* > > - Some acronyms need to expand when first use, e.g., A_NC_I, CA, SHSP. > > > Regards > Lizhong > > --e89a8ff1ccb4e24b5f05229fb481 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lizhong,

Thank you very much for doi= ng this review on such short notice.

I have update= d my ballot to request that the draft include a section about consideration= s
for selecting a hash function and the bits to use - so as to ma= ke the probability of
a network hash or node hash collision low e= nough to be acceptable.

Thanks,
Alia

On Wed, O= ct 21, 2015 at 12:02 PM, Lizhong Jin <lizho.jin@gmail.com>= wrote:

Hello,

I have been selected as the Routing Direc= torate 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 R= outing Directorate, please see=C2=A0= =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

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

Docu= ment:=C2=A0draft-ie= tf-homenet-dncp-11.txt=C2=A0
Reviewer: Lizhong Jin=C2=A0
Review D= ate: Oct, 21st=C2=A0
IETF LC End Date: =C2=A0
Intended Status: Standa= rds Track

Summary:=C2=A0
I have = some minor concerns about this document that I think should be resolved bef= ore publication.

Comments:

  • This draft provides an abstraction protocol specificati= on, instead of defining a real protocol. If authors could provide a realist= ic standardized protocol based on this draft, that would be more convincing= .
  • My biggest concern of this draft is the hash based network st= ate update. The draft does not describe the case of hash collision. If the = hash collision happens, then the network state will fail to update, which w= ill be a severe problem. Although it maybe low probability of hash collisio= n if we have longer hash length, but the question is, does the network coul= d accept one collision?

Nits:=

  • Some=C2=A0acronyms need to expand when first u= se, e.g.,=C2=A0A_NC_I, CA,=C2=A0SHSP.=

Regards
Lizhong


--e89a8ff1ccb4e24b5f05229fb481-- From nobody Fri Oct 30 15:28:56 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85201B31DB; Fri, 30 Oct 2015 15:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH6wEMPI-Jot; Fri, 30 Oct 2015 15:28:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0715.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:715]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5C41B31D7; Fri, 30 Oct 2015 15:28:48 -0700 (PDT) Received: from BLUPR05MB1985.namprd05.prod.outlook.com (10.162.224.27) by BLUPR05MB1987.namprd05.prod.outlook.com (10.162.224.29) with Microsoft SMTP Server (TLS) id 15.1.312.18; Fri, 30 Oct 2015 22:28:43 +0000 Received: from BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) by BLUPR05MB1985.namprd05.prod.outlook.com ([10.162.224.27]) with mapi id 15.01.0312.014; Fri, 30 Oct 2015 22:28:43 +0000 From: Ronald Bonica To: "rtg-dir@ietf.org" , "rtg-ads@ietf.org" , "draft-ietf-bess-virtual-subnet.all@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-bess-virtual-subnet-02 Thread-Index: AdETHvyA+CbjSvmqREeglMzCa8yrcg== Date: Fri, 30 Oct 2015 22:28:43 +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.10] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1987; 5:0btCLULS8iMVxXsMozxhK8O11Z3xsg2eaaTY7/gK8yEG0FP0H9KCoxjURMEiZYpJTfwb9rQqLyANO8/8VSyVdtv2gmCrcJdr3f6K2h0HxeBY9/gm3S9EPL7Ks2EriBdg8km1Gai5aA4xKcYdtSYKDQ==; 24:2lxrj/h02D3ZGi1F9SS+FmIEdg/PeOl55c9GsnPcnA4o+sJgto2hgHbXYc0WjB4q8KbfJNFvFcmXH005mQJov1w3C8jXtR0X6b0C6oYB0P8=; 20:AccnJdwbcnAXB0mmSABnjbr29SK/ZtahQn3vvdhWIA4XWiKe5o5iHinNAzBDZ4BwiKJae7/G9UEWxkUB6IxjvQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1987; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BLUPR05MB1987; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1987; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(54094003)(107886002)(15975445007)(5001960100002)(101416001)(92566002)(81156007)(33656002)(5004730100002)(102836002)(76576001)(189998001)(2501003)(10400500002)(74316001)(1720100001)(97736004)(105586002)(87936001)(50986999)(2900100001)(5007970100001)(5001770100001)(5008740100001)(66066001)(450100001)(77096005)(230783001)(229853001)(86362001)(122556002)(5003600100002)(5001920100001)(99286002)(5002640100001)(40100003)(106356001)(11100500001)(54356999)(19580395003)(2201001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1987; H:BLUPR05MB1985.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:23 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: 30 Oct 2015 22:28:43.5428 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1987 Archived-At: Subject: [RTG-DIR] RtgDir review: draft-ietf-bess-virtual-subnet-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 22:28:56 -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-bess-virtual-subnet-02 Reviewer: Ron Bonica=20 Review Date: Oct 30, 2015 IETF LC End Date: =20 Intended Status: Informational Summary:=20 This draft describes an L3VPN configuration that supports host mobility. Th= e configuration is described as follows: - VPN A contains two sites. Site 1 is connected to PE 1 and Site 2 is conne= cted to PE2 - Site 1 and Site 2 each contain a subnetwork. In both sites, the is number= ed 192.0.2.0/24 - Each subnetwork contains several uniquely numbered hosts - Each PE advertises a /32 for each host - Each PE runs proxy ARP Given this configuration, hosts can be moved from Site 1 to Site 2 without = much effort. The configuration described above will clearly work, without a= ny changes to protocols. I can imagine several variations on the configuration described above. Thes= e would also work. I wonder if the IETF wants to: - endorse this configuration over others - document the other configurations, also - document none of them, leaving the exercise to operator groups or individ= ual operators Since the authors have put considerable work into this draft, and the bar f= or publication as INFORMATIONAL is low, we might as well go ahead and publi= sh this draft. However, in the long term, the IETF probably doesn't want to= document configurations and deployment strategies. Regards Ron Bonica From nobody Sat Oct 31 04:24:47 2015 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068AD1B37AB; Sat, 31 Oct 2015 04:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M21Y-2SjVfD3; Sat, 31 Oct 2015 04:24:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C01D1B37AF; Sat, 31 Oct 2015 04:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2380; q=dns/txt; s=iport; t=1446290684; x=1447500284; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vB33u+yEKi7zysMc9ra/2QI1lZ/EJdeY7aAS2Wsrdqs=; b=bzPMR1JkaPNG3T+7GBTTGcYI1UtcOadxQvwELjG4cl9aBXtYTg6b942d c25PA7GkXYtgTNpnGWRyR+UxRRKFQm8YkBDsTVoSyv+Iz/5+jl4oJyP+j qpVQ2fQk+jeFGLgJ6VVmguO/oqBxJNM26CphkvExfBp2D0A2e8QpPvIcd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/AQBgpDRW/40NJK1egztTbwa/LwENgVohhXgCgRk4FAEBAQEBAQGBCoQ2AQEEOk8CAQgOBiIQMiUBAQQBEogwDcMrAQEBAQEBAQMBAQEBAQEBARuGdwGEfYlABZJmg10BhRyICIFZSIN3liEBHwEBQoIWGIFWcgGEdoEHAQEB X-IronPort-AV: E=Sophos;i="5.20,223,1444694400"; d="scan'208";a="46446574" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Oct 2015 11:24:43 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9VBOhAX009196 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 31 Oct 2015 11:24:43 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 31 Oct 2015 06:24:16 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Sat, 31 Oct 2015 06:24:10 -0500 From: "Alvaro Retana (aretana)" To: Ronald Bonica , "rtg-dir@ietf.org" , "rtg-ads@ietf.org" , "draft-ietf-bess-virtual-subnet.all@ietf.org" Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-bess-virtual-subnet-02 Thread-Index: AdETHvyA+CbjSvmqREeglMzCa8yrcgBJQ9cA Date: Sat, 31 Oct 2015 11:24:10 +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.70.231.64] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-bess-virtual-subnet-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 11:24:46 -0000 Ron: Thanks for the review! I had similar comments related to the overall value (in my AD review on the bess list a couple of days ago). Alvaro. On 10/31/15, 7:28 AM, "Ronald 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, >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-bess-virtual-subnet-02 >Reviewer: Ron Bonica >Review Date: Oct 30, 2015 >IETF LC End Date:=20 >Intended Status: Informational > >Summary:=20 > >This draft describes an L3VPN configuration that supports host mobility. >The configuration is described as follows: > >- VPN A contains two sites. Site 1 is connected to PE 1 and Site 2 is >connected to PE2 >- Site 1 and Site 2 each contain a subnetwork. In both sites, the is >numbered 192.0.2.0/24 >- Each subnetwork contains several uniquely numbered hosts >- Each PE advertises a /32 for each host >- Each PE runs proxy ARP > >Given this configuration, hosts can be moved from Site 1 to Site 2 >without much effort. The configuration described above will clearly work, >without any changes to protocols. > >I can imagine several variations on the configuration described above. >These would also work. > >I wonder if the IETF wants to: > >- endorse this configuration over others >- document the other configurations, also >- document none of them, leaving the exercise to operator groups or >individual operators > >Since the authors have put considerable work into this draft, and the bar >for publication as INFORMATIONAL is low, we might as well go ahead and >publish this draft. However, in the long term, the IETF probably doesn't >want to document configurations and deployment strategies. > >Regards >Ron Bonica > >