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: =?utf-8?B?MTtBTTVQUjA3MDFNQjI0OTg7MjM6NjZZVzBoNWtuSVdCMVdEbS9udmd3YzAv?= =?utf-8?B?VTFiNDQrOW5OU3dMM1ZDT3FpOFFGM05maGxBa1o1enJSVENXazUwTUw2cEhD?= =?utf-8?B?K0JBZ0RnUEVCRWUxRDdacHdMOGdOS0hGY3hEUm1CdUFoU2NGQkpQaHdqdjYy?= =?utf-8?B?UDJQa3ZYQkEyakNvTzJQUm9raFVZZnZlMXNLMWcyMFpidk01dHVEOHpOc0lD?= =?utf-8?B?M05WQnhUVzUvVWFEcHl2Sm9yR0JQK21Ia042dzhnUHBSVWUwZzNaUlVSMDJ6?= =?utf-8?B?by93eUNuRXAzWVVpRGM3NVV0MVJlOFlHVExaQzREVTRQdjRYUWZZQ2ZzM3JZ?= =?utf-8?B?L2hnQ2pVbFpzeUpRMk9DRTNreXR5WGdXQUMwMTNZQ1JHTXl2cWFNd1FjaTFZ?= =?utf-8?B?dUY5QmNSaGoxSys2VmpINmVsUG1ZUWllTTFFRzNRNjM5enhTQ2hkcFFGaVdT?= =?utf-8?B?Q2cxcUhiTXFvNE9DM0IyNW1iQllRSHFwK3J4alBTUDBjWitSOHI4Z0dwK0RR?= =?utf-8?B?ZWl2NStrSmlERG8zMmUxVWwrNFJFMzdjdFdnZFBTZnM3NWRLL1RyaUpHREFK?= =?utf-8?B?VTgzbDNubkdzOUV6WUtsbWhPZlFXbWFLcGg2K1hvZ1dITlFjeVdCWm1mR1Br?= =?utf-8?B?eFJ6aWQrbmYxaXZ3QlJyVlV1RWU5aUxkLzRydDdrTUhxL2ZVTEJ6VUtHYTk0?= =?utf-8?B?NEYwWll3VCs5ak42dnJIZTZPY3NoWG81dmNjLzlpK2tBY2p5SW45azNXOWw2?= =?utf-8?B?UDJrQlJUblRRWU90TFlOVkdDU3E3M2dFZHRMaTk1SlhGZlJzY2RBNW5Rd0Yz?= =?utf-8?B?VHpZeDhoTitjSWdoN01xN0xkcTd2cjUvSVVsRi83cVoxWmNaWkRKL294ZlRH?= =?utf-8?B?K3ZhZktiaHdTVUFYaUR5NnY3NjhUOU11ZzM4d3JCUlhQbDVLZENOWjJZbllK?= =?utf-8?B?cG91K0lkcjhneUF1Z0RaUDEvZG5MeXo4SHZCYlRtWDR6M284TElvOG1QeGpD?= =?utf-8?B?eHNrS2dmWWUybmpGN3c2Q3lZUGhubmdZT1BxRjFlZkhSZmE4ZDRkQnJhVUJi?= =?utf-8?B?ckxFLzBEUUVVdk5UN1BzNmxJNjBJaElTWUVqMDN5QVFRNXNrLzRlWTJJVHh6?= =?utf-8?B?azVWdU1HQmdsZVZBcG9CeHVhZ1FIM1JNRHpKTGwrUEc0VnYxdkl0VWx1cmFp?= =?utf-8?B?ZEM3Yzd3UTNpY3JOYk5uVUVWMTZqVFdjN1NqODh5RElFK01WbXcvV05wZ04w?= =?utf-8?B?bGhGai81YWVVME55N3Vwczh3dnJGZzYyVXJoeXpZTWhTT2RpS2xKUWJFWUN0?= =?utf-8?B?SnlhaUtKbWtPQ3JGdzg5S0RvblIvd2c5WS9KM0pma1Z0SXVlM3BJbzYwWFM1?= =?utf-8?B?a1UxT25Ka1ZMMEdoVGNuUnpyVExLTXlIcmJ4bzJ6Lzl2QmkzRGlwaHorLzhw?= =?utf-8?B?c2gzSFVmSXp5MGlMVFJjWFJXRTVPN0hjK3gvaUZUeVdTVy81VFlaVmVwT3R5?= =?utf-8?B?OWJUb29uRUlibTZ2d1gzY2lIczlXRGI3NnJOL0hqWXZIbk1ucEVseDhJcVV4?= =?utf-8?B?aDVTcTZnc3pIRTFXVTlEUHhlSWFSSTAzeDlKMnQxNkhoSzI4MExpajY2bklj?= =?utf-8?B?OTlpTmJVeHdwR0kwZUJ5MGVpSjhQUlo5cU5mZjVrUThINC95OUZjZ2pIc0ZX?= =?utf-8?B?MkliU2RxN0lpUVIvWTBzSnVZdFpGeUVoUFVrVzMyNnBOZ2d6WDdzUmlkZ0hM?= =?utf-8?B?VHhweG5sb3VuNFhtYjFuVWd4KytRTE9wd21wcllHNXNyR0NSMWhaWEpEaEpS?= =?utf-8?B?cVFRZmxJREF2cVhXZXR3Z1JKZ25qUXN2d1FXTTBpZ2tjUExpZm8zSk9xSmNJ?= =?utf-8?B?TklvYmFNWFJ0MzFkUjBXM21KY1V2aEU2NWpadTFrTWdXdU0vVm55RXY5UUQw?= =?utf-8?B?MmU1QTNkSWlya05NcVBFaExnb1llb05mQklrQjQvYzZEbkNuanAyOGVzYXY5?= =?utf-8?B?OFlmanFDR1ZHallMeVUwUlFkQkNFZlBGQ2RZWVdIdk1LajNOZ3ZqRjhYQVdp?= =?utf-8?B?QWpKaWZXMXIvQXZXU2FDdkhtSUhRWng3RlRJS3BpNlZyNDdTT1JDU25rU3Yv?= =?utf-8?B?MmJQUT09?=
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.