Re: AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06
Martin Vigoureux <martin.vigoureux@nokia.com> Wed, 12 September 2018 16:03 UTC
Return-Path: <martin.vigoureux@nokia.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6458130E64; Wed, 12 Sep 2018 09:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG2u6LoaGfw9; Wed, 12 Sep 2018 09:03:15 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30096.outbound.protection.outlook.com [40.107.3.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC68130E43; Wed, 12 Sep 2018 09:03:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IHJu7zF69V3yJjINygxIjwmZYV5x6mXVeIGWPmUBN5w=; b=WlrL2T7vqA2QgpmP5n+iUTZuqrm3HBPlop9SQ1bnAsr7PyNePa4WjmbMLOzRC9rAOIqXU6yyk5PfS2rpg/lQAY55PHpjbTUVugPtOqpJhIpmlESv1u4yx6NO7CuarFlYA6oT3D8mQJLVOlAFbLzj/rgMxUS/QEvbSsVvPxotcyI=
Received: from [135.244.231.21] (135.245.212.21) by AM5PR0701MB2498.eurprd07.prod.outlook.com (2603:10a6:203:10::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.10; Wed, 12 Sep 2018 16:03:09 +0000
Subject: Re: AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06
To: Pushpasis Sarkar <pushpasis.ietf@gmail.com>, draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org
Cc: rtgwg-chairs <rtgwg-chairs@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, RTGWG <rtgwg@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>
References: <2ccba50e-2032-bad6-b91d-cb583bd8cac6@nokia.com> <CAEFuwkixedEdM9t4iBytMBd=xNPmmuHxh=F8hmsGZ3Th12+BzA@mail.gmail.com>
From: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <0989548c-7dd3-712b-2f24-7ee2e2c3827c@nokia.com>
Date: Wed, 12 Sep 2018 17:58:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CAEFuwkixedEdM9t4iBytMBd=xNPmmuHxh=F8hmsGZ3Th12+BzA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.245.212.21]
X-ClientProxiedBy: AM6PR0202CA0017.eurprd02.prod.outlook.com (2603:10a6:209:15::30) To AM5PR0701MB2498.eurprd07.prod.outlook.com (2603:10a6:203:10::14)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 171bfd4e-32cc-4950-b8a5-08d618c93c15
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM5PR0701MB2498;
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2498; 3:1k+BVlgNVksrsm7XtxEgUtS07zunWYsv6w6ZiYg8/ND9X7OBqFUQInzIy83tZCg2sLAbS91nfP9i0y6xhS28wNVuFh2DfL6FtZ8IW1/HQUiQU7+QDTy7Q91evZO7IXmNj2aXCNUBOmhHDP7JLpyoQc2qWXtwxYfQdE50DmvIGUc1zTvl1zHazZMGRFi3ZHK1dDH2nTCScB16S1F9b7Olj8c33DXkb/326UgXjx8qN7VGo43vwv8EmBvZGk9AXpyh; 25:aXINKc62tqAoZwoUw0xxU7O/CEjPzft3aIznCkVwlf/8oj73aAD9oF4sWu8RnxTedc41KBa+Cq1HuaSw/nbm2+7q7x11cVAxVfVpeuHz46umsEh7qzACXwdGyv7/er36axYztSo09GimLxIfKFV/8yVbSIbej8oS0IB22DyxFVTQTOq3jBADoChEM38g+nUB0qilghzRdY7EOqCvI9wsnoeQJ2szGtlmHGZLwm+Yfs/AiQy2emsNWkVEqzUWCW3xjzqMTfEgVqYI3D9KO+vSTJ7FqiwlXnWbdIdk560Na7htZO5y95jweriXBHGU98IeNkrA6XZ4iDbInYt9fIcDzg==; 31:pUjFt2m0KnE3K/VId4yKLy8SnhLHDVNmC1rR7Y6fZ65J8AUmz/33ObSWvz7x9bMTZ9rDcDHK8vcPhBpniiu4boMJVj7LqsDNUBj51oMJaqdYXc4dfVVpMAgirk1Y+bEqWmMIIeRiNqnfMwajwXqBD5DRKiNwWCTEec5jQsKOJ+TkgB2CeB/w6au8wJYIoETdpFfX2iC/hN5+vESBY4F+rQfgUkwhoNjkxBx4lbCDuYQ=
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2498:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2498; 20:mzYQJA5KctKi9pxjcf/WBHJp97Bx0PHkPF/x/DbocZQGA6amYJ+i2S04mj6rXCRzhCPvcde2zcYa4R9yHKc9A53eqnvuFLmAIHSqW3/dXW9IhCXf2EKTN9n1/PRyDZEJ+Ei1ENxdpxnI33ru4Vkkwwtv6OUVrpH7mpHkndssZsfhwXYBB70gV1GXqbBhkV9Q17BwVkgd80vB5L9F0Ot7uRwsbcdjycX0eFEV+wDhFgSanL1KhV7+rtqbY7xsbh80ww+rbMHUMOyMdi+c7tD+tOsK1XcnqueDw9cw9fXn3fF0VfT6+qoBMCW9FIu5NLcicM0zDkZnfjkc2rgcC5U/kcqm9ZTDUxoWwJq4bM+cVvhIohQ0+6FMOABeBx7ed74E6yuRYPyICrapRIK8darL6kXastadOFPCZ5Y0I2M0Uq2ezifWcZdlZzpExSLsRQW/2vG4hJwnKTQ8bj5jbfORFo0AC3LvioW8XBhFG5oWoZkWytZs9/QKBvpEg1MPTdRJ; 4:bnHpOi8jnrMHC5iPRz56QYZwVX1hx7a+1huq9sFYqMWqmSwNSRfmX4j1xYnxmrDKy2ftZbS7A1Y5atR6mb9gVa4waYLnO32KW7IuGoT7LG1Qi8Gjf9ofTgONrFYGtruDZuLTOxtWtFjmwyTPlw6vW6lwvZs0XHVwlxz4+Dz5y2czcD2IqBKtZGsm91KjJz9iZeRtZupTKnjlX+iGkDWhj3NzNImYbGDyVOtXY5boavcMFjPG8Ce54lsBMq4GlojQI80SLB3DKFhNcTMJ+uqoeebmdDvSZKv4uhGNBTHspo+Is82ACqL4Ad1fLhABC0Jh0ZfwdQZLuezpphtHMPE3EUgvuI2G0xyr2HZDUwOs6UQ/wCn1/YhgoWQKgSMPCQcZ6RIl17FeJw8Pz0AU+mBpn3Mjr3b0sk49c+U+mpOEB1s=
X-Microsoft-Antispam-PRVS: <AM5PR0701MB2498429C0F754BA6D1A076F18C1B0@AM5PR0701MB2498.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(82608151540597)(109105607167333)(195916259791689);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823302020)(3231344)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699050)(76991041); SRVR:AM5PR0701MB2498; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2498;
X-Forefront-PRVS: 07935ACF08
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(39860400002)(396003)(346002)(376002)(136003)(199004)(189003)(16576012)(54906003)(6246003)(16526019)(47776003)(3260700006)(68736007)(316002)(305945005)(25786009)(7736002)(956004)(486006)(23676004)(52146003)(2616005)(81166006)(52116002)(11346002)(8676002)(53936002)(65956001)(65806001)(476003)(81156014)(67846002)(49976009)(26005)(76176011)(86362001)(386003)(107886003)(345774005)(66066001)(58126008)(3846002)(446003)(2486003)(50466002)(6486002)(4326008)(8936002)(478600001)(106356001)(105586002)(6116002)(31696002)(2870700001)(97736004)(31686004)(64126003)(5024004)(14444005)(2906002)(65826007)(39060400002)(44832011)(5660300001)(36756003)(229853002)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2498; H:[135.244.231.21]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;AM5PR0701MB2498;23:66YW0h5knIWB1WDm/nvgwc0/U1b44+9nNSwL3VCOqi8QF3NfhlAkZ5zrRTCWk50ML6pHC+BAgDgPEBEe1D7ZpwL8gNKHFcxDRmBuAhScFBJPhwjv62P2PkvXBA2jCoO2PRokhUYfve1sK1g20ZbvM5tuD8zNsIC3NVBxTW5/UaDpyvJorGBP+mHkN6w8gPpRUe0g3ZRUR02zo/wyCnEp3YUiDc75Ut1Re8YGTLZC4DU4Pv4XQfYCfs3rY/hgCjUlZsyJQ2OCE3kytyXgWAC013YCRGMyvqaMwQci1YuF9BcRhj1K+6VjH6elPmYQieM1EG3Q639zxSChdpQFiWSCg1qHbMqo4OC3B25mbBYQHqp+rxjPSP0cZ+R8r8gGp+DQeiv5+kJiDDo32e1Ul+4RE37ctWgdPSfs75dK/TriJGDAJU83l3nnGs9EzYKlmhOfQWmaKph6+XogWHNQcyWBZmfGPkxRzid+nf1ivwBRrVUuEe9iLd/4rt7kMHq/fULBzUKGa944F0ZYwT+9jN6vrHe6OcshXo5vcc/9i+kAcjyIn9k3W9l6P2kBRTnTQYOtLYNVGCSq73gEdtLi95JXFfRscdA5nQwF3TzYx8hN+cIgh7Mq7Ldq7vr5/IUlF/7qZ1ZcZZDJ/oxfTG+vafKbhwSUAXiDy6v768T9Mug38wrBRXPl5KdCNZ2YnYJpou+Idr8gyAugDZP1/dnLyz8HvBbTmX4z3o8LIo8mPxjCxskKgfYe2njF7w6CyYPhnngYOPqF1efHRfa8d4dBraUBbrLE/0DQEUvNT7Ps6lI60IhISYEj03yAQQ5sk/4eY2ITxzk5VuMGBgleVApoBxuagQH3RMDzJLl+PG4Vv1vItUluraidC7c7wQ3icrNbNnUEV16jTWc7Sj88yDIE+MVmw/WNpgN0lhFj/5aeU0Ny7ups8wvrFg62UrhyzYMhSOdiKlJQbEYCtJyaiKJmkOCrFw89KDonR/wg9Y/J3JfkVtIue3pIo60XS5kU1OnJkVL0GhTcnRzrTLKMyHrbxo2z/9vBi3Diphz+/8psh3HUfIzy0iLTRcXRWE5O7Hc+x/iFTyWSW/5TYZVepOty9bToonEIbm6vwX3ciHs9WDb76rN/HjYvHnMnpElx8IqUxh5Sq6gszHE1WU9DPxeIaRI03x9J2t16HhK280Lij66nIc99iNbUxwpGI0eBy0eiJ8PRZ9qNff5kQ8H4/y9FcgjHsFW2IbSdq7IiQR/Y0sJuYtZFyEhPUkW326pNggzX7sRidgHLTxpxnloun4Xmb1nUgx++QLOpwmprYG5srGCR1hZXJDhJRqQQflIDAvqXWetwgRJgnjQsvwQWM0igkcPLifo3JOqJcINIobaMXRt31dR0W3mJcUvhE65jZu1kMgWuM/VnyEv9QD02e5A3dIirkNMqPEhLgoYeoNfBIkB4/c6DnCnjp28esav98YfjqCGVGjYLyU0RQdBCEfPFCdYYWHvMKj3NgvjF8XAWiAjJifW1r/AvWSaCvHmIHQZx7FTIKpi6Vr47SORCSnkSv/2bPQ==
X-Microsoft-Antispam-Message-Info: guglYwaxkU4naQ0bq22A3+BY/WuXjqdZYyEyse2UpbfTKUZ7H70GHEbxYw6xPQQccgnXWS1gXUBzTbhVUWWxSOTJpqio+sAtTncSQpNGDo5A7L52r1zuFfvwFW4EK6j/Szri50PdM0K+CEKYDrXFDJGjos6lYhzA2hz1dzycUmBCw6a2ipghyPyooj+Cl1SiC4P2mr9VJxFuDCwm3hgzC0pgUBoJ8KgUDtn0+oNukz4kQIPIRLAX5F8aWgG1dtG09m0rw0QvZF/7tBR0OHBZWG/3a5G2GjhmB9c6a8ZazbA4XzfRVGUJv2A0nfUgAVohXQrcBzDz5L7n9r1cas9pzUNKuAcSWbB8Kwpmei+wEAmDZ2U7FZiWOxsVGk2xLTvjJu7nwMVfDyCZFesIewfOwg==
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2498; 6:roDz7P4NcUpxhKuvl65ytMibvMrmfXUX5s4jaSeR9vgfFod4NdmZUIMeqqjjMVFRe5LEyLeECNJsNgUv64QAuzVKeMgdsCE1bwpKhyIhrcPhB+bSC+P0y+YAJpHBq8Q2PLTYVf5B22VmeRlrGyPdRKDDt9EcvKKFxCeMEl9utSRimxBgeveRCjPMWBchAmQlw17TbsagNtf9v51RU7FxxdSAEMdMJE9ncLNmv7YqPLiAsmt0g3LsYpImlrU0DCJ6VG1zri/6TGq6getoxF7LxsCTuKDzRYO6iDBVJHPGGXZdxNs0sEXbmjDyf1AGEDvKtmApYM2/XAqI1iFWSIPJhCyslUDV4FSp8iU9FD78bWsxx6hSF80dTbwK7iY6vHeMrIrJ3ER1QcSDrMt34lvLTyqEII3l+15jCR+9i7ll3c/wNuEKNC2orABhZDguTwH6AEV/NLEQOcgUW61syBTftA==; 5:cQoGqyySnwGdz6tzFdyCKiU/Zkn2G1JoPanm+3g80fHgj3u6UDX5gc6wynzkkPWAZDSnyf2wOcEMM8zXRWofUeyVTGS3sLMTI/J/zv5TpumSgbLe/eIBeh/TVjQEkILpkrAbXxZE2u7Lfe60QihKVbd+F2D9Wur2QDaSwOtuJlo=; 7:VQhkSyft5saFrVnoWkSS4vC7A0Wgzx6a3UJPYvKBweFzxysfv604l+2oErsBiOCMcioWCy6r1+Woje2zPHSi+zXVNKZjTL5ju6/EYYjzsEQcF33R2qJ03vVHYxKbpxYHkPhxE4bV1DX+KX9hxd+krk5EUSQuowlW2BBxwJB93TAU91WeVNgErk8mAQRyXoS+TIzyFtch0CEMbN3a5DEmrwAjmZd7/UTnTCMa05jN5fB7OrtBeFhhJ0P1jgLZwYJj
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2018 16:03:09.2311 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 171bfd4e-32cc-4950-b8a5-08d618c93c15
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2498
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/878ijxupO1ls38DZ4WQsQDzuHnY>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2018 16:03:19 -0000
Authors, am I right in thinking that the ball is still in your camp and you need Shraddha to look at some of the comments? The draft has been in Revised I-D Needed for 5 months now. -m Le 2018-06-19 à 11:00, Pushpasis Sarkar a écrit : > Hi Martin, > > Once again sorry for the delay. Please find answers to some of your > points inline. > > Hi Shraddha, > > Please find attached the XML draft for the next revision with changes > taken care by Uma and myself. Please add your changes and reply back on > the comments on OSPF sections that I have requested you to take look at. > > Thanks > -Pushpasis > > > > > On Wed, Mar 28, 2018 at 3:29 AM Martin Vigoureux > <martin.vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>> wrote: > > Hello Authors, WG. > > Thank you for putting together this Document. Thanks also to all those > that reviewed it. It is well written and pretty clear (more the first > part than the second though). > > I have a few comments, all of them minor and mainly intended for > clarification. > > However, I'd like these to be addressed before moving to IETF LC, just > to avoid them being picked up again. > > thanks > -m > > Abstract > s/This documents/This document/ > > [Uma] Done > > Requirements Language > Please switch from 2119 to 8174 > > [Pushpasis] Done > > Section 3 > I am under the impression that few clarifications are needed here. > The Document says: > Link-Protection + Downstream-paths-only : > ========================================= > 1. Evaluate the link-protecting + downstream-only LFA > inequality > > and: > When computing a downstream-only LFA, in addition to being a > prefix- > originator of P, router N MUST also satisfy the downstream-only LFA > inequality specified in Figure 1. > > * do you mean: MUST be prefix originator of P and MUST also satisfy? > * this paragraph basically says (taking out the prefix originator > part): > if one wants a downstream path only LFA then the downstream path > inequality must be satisfied. This seems like stating the obvious. Is > that needed? > * step 1 above makes no reference to N having to be prefix > originator of > P. There is thus an ambiguity between this last paragraph and > description of the steps. > * Also, strictly speaking there is no "downstream-only LFA inequality" > in Figure 1. That inequality is in RFC 5286. Figure 1 shows the > "Link-Protection + Downstream-paths-only" inequality. > > [Pushpasis] As far as I understand LFA.. 'Downstream-paths-only' > implies link-protection.. A alternate neighbor N which satisfies the > Downstream-path-only criteria also always satisfies the > link-protection inequality. Nevertheless I will modify the text to > be specific. > > The Document also says: > In case an alternate neighbor N is also one of the > prefix-originators > of prefix P, N MAY be selected as a valid LFA for P since being a > prefix-originator it is guaranteed that N will not loop back > packets > destined for prefix P to computing router S. > > However, if N is not a prefix-originator of P, the computing router > SHOULD evaluate one of the corresponding LFA inequalities, as > mentioned in Figure 1, once for each remote node that > originated the > prefix. In case the inequality is satisfied by the neighbor N > router > S MUST choose neighbor N, as one of the valid LFAs for the > prefix P. > > These two paragraphs are in the main body of the section, giving the > impression that their applicability is global to the three cases. It > looks to me that they are only valid for node and link protection > cases. > I would clarify that. > > Also, in the first of these two paragraphs, the use of MAY suggests > that > one may not select N as the LFA, but the description of the algorithm > does not give this degree of freedom (If .. select ...). So, is that > a MAY? > > [Pushpasis] > > I have re-structured the 3 paragraphs into following 2 paragraph.. Hope > it addresses all your concerns.. > > " > > In case an alternate neighbor N is also one of the prefix-originators > of prefix P, N being a prefix-originator it is guaranteed that N will > not loop back packets destined for prefix P to computing router S. > So N MUST be chosen as a valid LFA for prefix P, without evaluating > any of the inequalities in Figure 1 as long as downstream-paths-only > LFA is not desired. To ensure such a neighbor N also provides a > downstream-paths-only LFA, router S MUST also evaluate the > downstream-only LFA inequality specified in Figure 1 for neighbor N > and ensure router N satisfies the inequality. > > However, if N is not a prefix-originator of P, the computing router > SHOULD evaluate one of the corresponding LFA inequalities, as > mentioned in Figure 1, once for each remote node that originated the > prefix. In case the inequality is satisfied by the neighbor N router > S MUST choose neighbor N, as one of the valid LFAs for the prefix P. > > " > > Section 3.1 > This looks like a duplicate compared to the paragraph which sits above > it in the Document: > The approach specified in [RFC5286] Section 6.1 last paragraph, > is to > simplify the MHP as solely attached to the router that was its pre- > failure optimal point of attachment; though it is a scalable > approach > and simplifies computation, [RFC5286] notes this MAY result in > little > less coverage. > > [Uma] Taken care of. > > Section 4.2 (and subsections) is (are) a bit difficult to > read/understand because of the typos but also because of the way it's > written. > > Section 4.2.1. > Do you mean ECMP FRR rather than simply ECMP (as section 4.2.3. > seems to > suggest)? > If so, please take this into account while addressing typos listed > below. > > [Pushpasis] 4.2.1 is for ECMP. ECMPs do not count as alternates. These > rules cover all scenarios but related to alternates only. > But, I will let Shraddha confirm that.. > > Sections 4.2.2., 4.2.3., and 4.2.5, seem to be linked to 4.2.1.. > Wouldn't it be better to switch 4.2.4. and 4.2.5.? Alternatively can't > these three sections in fact be subsections of 4.2.1 ? > > [Pushpasis] Shraddha can you take look and let us know if that is okay. > > > Although Sections 4.2.2., 4.2.3., and 4.2.5 seem to paraphrase > 4.2.1., I > read one sentence which does not appear in the pseudo algorithm: > If there are two ASBRs with different type2 cost, the higher cost > ASBR is pruned. > So I am not sure to understand when this condition/action comes into > play. Could you clarify? > > [Pushpasis] Again will let Shraddha comment on it. > > > Section 4.2.4 > It is not clear which inequalities will apply in that case. > > In the same way as above, Section 4.2.5 seems to say a more than Step 5 > of the pseudo algorithm. Could you clarify when the extra conditions it > describes come into play? Or said differently, shouldn't step 5 be > reworked to be more complete? If you do so, please rework that step > incorporating the types of changes/rephrasing I have suggested for the > other steps (see typos below). > > Section 9 > I don't disagree with what is written here, but do you think this is > sufficient? > > [Uma]: Added bit more specific to ISIS and OSPF security docs. Check > that out. > > Section 10 > Shouldn't rfc5714 be referenced since the inequalities use the > principles set forth in that rfc? > > [Uma]: Done. Added a sentence in the first paragraph too. > > > Typos/Editorial comments: > s/for a multi-homed prefixes/for multi-homed prefixes/ > > [Uma] Done. > > s/This document also provide/This document also provides/ > > [Uma] Done > > indentation on second line: > Cost (X,P) - Cost of reaching the prefix P from prefix > originating node X. > > [Pushpasis] Done > > s/Else, evaluate the link-protecting/Else, evaluate the Link-Protection/ > > s/Evaluate the link-protecting + downstream-only/Evaluate the > Link-Protection + Downstream-paths-only/ > > s/Else, evaluate the appropriate node-protecting/Else, evaluate the > Node-Protection/ > > s/one of the corresponding LFA inequalities/the corresponding LFA > inequality/ ? > > s/a router compute/a router computes/ > > [Uma]: Done. > > In Section 3.1, please capitalize 'p' in text and figure to be > consistent with the rest of the Document and the Terminology section. > > [Uma]: Done. > > In Section 3.1, please capitalize 'p' in text and figure to be > consistent with the rest of the Document and the Terminology section. > > s/a MHP/an MHP/ (not sure about that though) > > may be it's only me but these sentences are hard to parse: > This document specifies, potentially > a node MAY consider a default route is being advertised from the > border L1/L2 router where ATT bit is set and can do LFA computation > for the default route. But, when multiple ECMP L1/L2 routers are > reachable in an L1 area corresponding best LFAs SHOULD be given for > each primary next-hop associated with default route. > > > [Uma]: Done. > > s/Inequalities described in sec 2 would also apply to multi-homed > external prefixes as well./Inequalities described in Section 2 would > also apply to multi-homed external prefixes./ > > [Uma]: Done. > > s/Loop free Alternates/Loop Free Alternates/ > > For the selection of alternate ASBR for LFA consideration, > additional > rules have to be applied in selecting the alternate ASBR due to the > external route calculation rules imposed by [RFC2328]. > remove "in selecting the alternate ASBR" > > [Uma] Done. > > OLD > This document also defines the inequalities defined in [RFC5286] > specifically for the alternate loop-free ASBR evaluation. > NEW > This document defines inequalities specifically for the alternate > loop-free ASBR evaluation, based on those [RFC5286]. > > [Uma] Done. > > 1a. if primary ASBR and alternate ASBR are intra area > non-backbone path go to step 2. > do you mean "belong to" rather than "are"? > > 2. If cost type (type1/type2) advertised by alternate > ASBR same as primary > Do you mean: > 2. Compare cost types (type1/type2) advertised by alternate ASBR and > by the primary ASBR > > [Pushpasis] Shraddha, please take a look. > > s/If not, same /If not the same type/ > > [Uma] Done. > > 3. If cost type is type1 > 3a. If cost is same, program ECMP and return. > 3b. else go to step 5. > Do you mean: > 3. If cost types are type1, compare costs advertised by > alternate ASBR > and by the primary ASBR > 3a. If costs are the same then program ECMP and return. > 3b. else go to step 5. > > [Pushpasis] Shraddha, please take a look. > > 4 If cost type is type 2 > 4a. If cost is different, skip alternate ASBR and > consider next ASBR. > 4b. If type2 cost is same, proceed to step 4c to compare > compare type 1 cost. > 4c. If type1 cost is also same program ECMP and return. > 4d. If type 1 cost is different go to step 5. > Do you mean: > 4 If cost types are type2, compare costs advertised by > alternate ASBR > and by the primary ASBR > 4a. If costs are different, skip alternate ASBR and > consider next ASBR. > 4b. If cost are the same, proceed to step 4c to compare > compare type1 costs. > 4c. If type1 costs are also same program ECMP and return. > 4d. If type1 costs are different go to step 5. > > [Pushpasis] Shraddha, please take a look. > > While selecting alternate ASBR for loop evaluation for LFA, these > rules should be applied and ensured that the alternate neighbor > does > not loop the traffic back. > I'm not sure about the meaning of the latter part of that sentence > ("and > ensured ...") > > [Pushpasis] Shraddha, please take a look. I think it means.. "... these > rules should be applied and to ensure that the alternate neighbor does > not loop ..." > > Figures 6 and 7, please add: > P - The multi-homed prefix being evaluated for > computing alternates > > [Uma] done. > > s/Section 3.5 and 3.6 of [RFC5286] describes/Sections 3.5 and 3.6 of > [RFC5286] describe/ > > [Uma] done. > > s/as defined in for IS-IS/as defined for IS-IS/ > > [Uma] done. > > s/destined to D2 continue/destined to D2 continues/ > > [Uma] done. > > s/ISIS/IS-IS/ > > [Uma] done.
- Re: AD review for draft-ietf-rtgwg-multihomed-pre… Pushpasis Sarkar
- AD review for draft-ietf-rtgwg-multihomed-prefix-… Martin Vigoureux
- RE: AD review for draft-ietf-rtgwg-multihomed-pre… Uma Chunduri
- Re: AD review for draft-ietf-rtgwg-multihomed-pre… Martin Vigoureux
- Re: AD review for draft-ietf-rtgwg-multihomed-pre… Pushpasis Sarkar
- RE: AD review for draft-ietf-rtgwg-multihomed-pre… Shraddha Hegde
- RE: AD review for draft-ietf-rtgwg-multihomed-pre… Shraddha Hegde
- Re: AD review for draft-ietf-rtgwg-multihomed-pre… Martin Vigoureux
- Re: AD review for draft-ietf-rtgwg-multihomed-pre… Pushpasis Sarkar