AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06

Martin Vigoureux <martin.vigoureux@nokia.com> Tue, 27 March 2018 21:59 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 6455712DDD2; Tue, 27 Mar 2018 14:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 CM78_BfPr1P4; Tue, 27 Mar 2018 14:59:08 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0124.outbound.protection.outlook.com [104.47.1.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF8A12DA51; Tue, 27 Mar 2018 14:59:04 -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; bh=kql+ZYHd+przIdpTERZYyV4MzfW9+pWAMdWPhycNGZU=; b=WJTG+lOdvaMs9nbcnCJNBNpiHirZsOaRlWd6cNtjgjPRaSQ8/sMclxpN8amU2ql4SeC9PeqGIa0q7FkLOxzglD6Hekw5h5OtzRp1sRW69RlbTlEGCgnYVf3bnUX15NZEXaYMRSTh1xRh6VzXOHl4rFMw3GXjHLILJL3bW5cJh5U=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
Received: from [IPv6:2a01:cb04:a1a:4c00:a9da:cc94:c448:2ec5] (2a01:cb04:a1a:4c00:a9da:cc94:c448:2ec5) by DB6PR0701MB2133.eurprd07.prod.outlook.com (2603:10a6:4:50::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.631.5; Tue, 27 Mar 2018 21:59:01 +0000
From: Martin Vigoureux <martin.vigoureux@nokia.com>
Subject: AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06
To: draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org
Cc: "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, rtgwg@ietf.org
Message-ID: <2ccba50e-2032-bad6-b91d-cb583bd8cac6@nokia.com>
Date: Tue, 27 Mar 2018 23:58:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-Originating-IP: [2a01:cb04:a1a:4c00:a9da:cc94:c448:2ec5]
X-ClientProxiedBy: DB6PR0402CA0019.eurprd04.prod.outlook.com (2603:10a6:4:91::29) To DB6PR0701MB2133.eurprd07.prod.outlook.com (2603:10a6:4:50::12)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 7753983e-24cf-4a9d-3080-08d5942df310
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DB6PR0701MB2133;
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2133; 3:rvkV+Cug76WcRDj//aH8AEfbch7bq32DD1Y+E6rU/vKC3WxhTaTnvK863y0doaA6GITmaqf/T6W9VuHIDrtSgwsXvXq5lEsSM3jWdCoUnZ9Gz8UarwiQv0wZs1MWlPQ6Roq+b+Y6dZlzcBhre4jX+SVgbbuFg60ys1VqfBfQfTCwExdwyeNoQuU73EJrog0pLvfyIryywxYr5IvIDJN67QFG3s9uwErdnhI9JvExz7Wf2HD6fBG/A/ekXQpy1hxB; 25:QXXR7l+Qar7Ha/dqN+ci7zbmxbPzGFI3slBB8p6SAzr+5+gUDIrTiUwDx/iZgRFLBWmhpELlNXtaNsuJYVeZkwwSfFU4Up4h/x9Tjke8AGvqGRL85kOVGnQ+eTiaMZpnrGoNoqI2pbGBLviV3gg8J4u+A7iFJQD8FEiYcUce6DXzzKXCLQ8f+ahQhhytdDQPCXWa1gnXGGm+LQbkeQ7BSJ7OXjXra7xyQP/FkpG+dZCwkKXCVZYT8S+KbkuG1sCCiG+DuuyFoHumhAvzaO4jAhT16rpDardCniNnIJANr8gp02wRPNJXaVdKDCZ9zN4cIY1lAc3pjlIl6V0AnmcO0Q==; 31:TzZkveJbY1or5QkytJtFBwYuF+spXtb32P3F+omducegRiS4UF+fPg5QPMtw7ZnRvqViK/B0aA/gfol0rQifosWJuxs9byenyiiahqqieZ0gaYzEVieUH4BHf9Hf3F9sRmStnO6wFPzbm2Q56m+XHRkBjDvwitu7w4/yfIR2WM79xiRcafQdazcuZF4ZsqSMfaGDVp3vJZ1lUZwe7mEQyp/N3xOpaDtbP2HO3qhXLTU=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2133:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2133; 20:Y0iBRB11CxHYYeqV9GJaT67rTph+xLehzd0qOwBw9qvuaHX9trsgXGs8qcka/0K+JzM5/FURyLw9NfgnY2cZ+scGWQpVZC9vFEo0FDQwrhc5BQKeT7SVDfM9PL5F6M9jw16hJr7UVFKUiSQ8xJ307OCmsCQsj1DqXmduOuaZZb6Hzas0SBT15Od5MiFNCR+KoFLmiZ2yoeSoLXmiQhFcQggMJFO6wtz7oR6HynB88J0hLKkRUoqAUHQmcsNdjygitdgfw/5xa2IwtJEoOqtsulEUm+w6dIHyEYW+zf7PxIJCAyRLtpE4/MI+WKiUiR5JG4q35XJW26zWPvXQIjsrM+DeAV1S4s555x3BJZleZIl9FXSGhRs3M5udeKbwKB/aoNIASbHCJEH9dvtwmlJXpofMm1eozF3QpDfBr2WdFDO5+ZT2xuRgyGw5lWC717Be+oScNOVSECd9I6v7/2+SX+F2lKisQ/PGCrGABPS3SLSXYFcaxQ71NLDt22TSPE56; 4:Bci/tC3FnHqGxSmrPKcm2p+8R6E6mF1MbITHjQH2mWa1cyNS9hO6N9nXf1tURwCEjXnpB5vW312FlNDVkoVnACYRnlMm+w+fZgWRZYqlKNMddNl/smNfOWB+QQ/edTp3YhaluGLMLcxTKXCwdVfJix7HoDazFPx5T6RiToDJn/9V4nhgFzCPe14yEQ2Wlm7czg2m6ZnnTgQbPEJQ8VrhpcW0qYTKj6M6MmkXAqCG7Koktqdx7ItLhO+ZTYR8v9VO/+7BRycRUZldfZHINXLFuw==
X-Microsoft-Antispam-PRVS: <DB6PR0701MB21331BC7370D90E1E74C1C208CAC0@DB6PR0701MB2133.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231221)(11241501184)(806099)(944501327)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:DB6PR0701MB2133; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2133;
X-Forefront-PRVS: 0624A2429E
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39380400002)(376002)(39860400002)(366004)(189003)(199004)(2361001)(6916009)(6666003)(36756003)(52146003)(46003)(81166006)(31696002)(2351001)(5660300001)(186003)(81156014)(97736004)(65826007)(8676002)(16526019)(3260700006)(25786009)(50466002)(58126008)(478600001)(316002)(305945005)(23676004)(59450400001)(52396003)(105586002)(52116002)(386003)(7736002)(2486003)(4326008)(67846002)(106356001)(86362001)(68736007)(64126003)(54906003)(31686004)(6486002)(2906002)(53936002)(5890100001)(230700001)(1706002)(6116002)(486005)(2616005)(39060400002)(65956001)(345774005)(65806001)(47776003)(486005)(476003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2133; H:[IPv6:2a01:cb04:a1a:4c00:a9da:cc94:c448:2ec5]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjIxMzM7MjM6NC9mQUdqanhFcGtGR0tHVFFQeCttT2Rr?= =?utf-8?B?bmJIaUlSTTJBWnRuWU9HQWNIZXBNY01sUW5BZHhOTDBSTWt4ZUxxTlVSQTdi?= =?utf-8?B?d2d6RjZkc1FkZzVCMCtHQTFhbDh1djUzYWFMWUZHb2dKblhxYVh3NEZOZnhz?= =?utf-8?B?ZTBlNFFjNGVkR0MvV0hGcjJ6dDhLTzE1dzBmV0ExR1oxRHRMc0xmOTd3akEv?= =?utf-8?B?WmpRV1JkNFZoNENxNXVUOGZJWDYzMzZFQXJleC9LQ3FWdWplWm1jSnVRUklu?= =?utf-8?B?N1UzT2U0YkxHN0gyVWRmYitTRzF5RmpEUk11T1lPaWZzb0Y4eXRTanBvMXYw?= =?utf-8?B?akhlWlRQWEpWcE1lQ25PL0hXcG9QMXFGY3I0WGxFczFDUU5CVURwUFB4ZW5k?= =?utf-8?B?eGFQcEQ2c1Q0TVY3blA1RXd4eHJKK1VLdWtBYkZYM1hiZVVMaEFWMkY3OEFt?= =?utf-8?B?UHdpZUEyWkQyejBWLytLaFhkcUJVelplTmVwc05yT0VjMXpyU3QzM0RFWFYz?= =?utf-8?B?bVlwUWkxeERyaUFzTjJ0V29xZ2VNT09OaHNIZjhDQS93c1dJbzcvMGx1bzdO?= =?utf-8?B?TXFNMHg0RUNBVjUyRjgvNmNUL1VBTFp1cW1ZRzZXMjNwek8zYmducGt3K3Zm?= =?utf-8?B?YjZMWU9zZVQvam9FYXBHd05CaytvOGloeEJNS29yb1JKc0hxUnU3SjNEUXZl?= =?utf-8?B?cUp1eHdrVyttOFdZdGZocFNPSW4yY0EvN2l0RnhzRlRTaVlqSy9Rd1hjREhR?= =?utf-8?B?bHZtUjh1RWRnWVg3aXNxUzZ2aDdYa09IU1lIZTRJS3d3T2xaM2liS0pMWmps?= =?utf-8?B?V25zcVdpV3lQbldvY1kwdmNWTXlPVTBpMDhmaXBmY0doOXlmNnN5RlJEZWtL?= =?utf-8?B?T3ZzdmErNk5UK2xxMjFoY2RQTzNXODNzNm0xYUVvMFRYZTE3UmVqd0hUdDZO?= =?utf-8?B?aDQyUEdUd2U2bGdFaUM0WFovdnZwdU00TWg3MHhaNXZOTVJKODBhMnVHWDRy?= =?utf-8?B?UXdqSHlRdG9hb2loWU84VlNZOEVZTE5WSDlLWUZocU0vREs1alc4WVFHNDdP?= =?utf-8?B?andZMGhTRGk3VUF6N3ZiQk44eFY0R0xONmJWMThRRnB5TXpNa2traDRnQ0dx?= =?utf-8?B?Q0xBUEtHSCsvTThYVFE3Wm1xWllmR2swekkrbnA4MEpxVWVvUFUxbTdUVVRK?= =?utf-8?B?dDZ5ZWFWaWM0SDV2dTR6YXVNa0FodU9KWUY1dEtmc0pMU0JGWFJyNkdhVGVS?= =?utf-8?B?VFVCMFlrczYxdURZWjQ1WTVXdmRhV2crK284aE5aQi94ajVDREI0UWVqTTZS?= =?utf-8?B?a0VRc1ROU2x1TCs2T3lhODBuTEp6UlpHMU1YTnNOakxRRDgrTE5rcFhFSjli?= =?utf-8?B?aytEa1JRZEJTRkowNHVjanMwNnhhaUtROFplMDU4elpEZE4wcURCMWVMa1c0?= =?utf-8?B?bmxmWVllNzd0eVBiMVM5eitMc0xKc0lVejZ1eE13b1l1djRzMDRtUjdBaUxI?= =?utf-8?B?aEJob3BtWEV5bElVUFhMTisybTJOZTRQb3ByRGFob0NBZzBmM0VCY0tOYWNx?= =?utf-8?B?dU9nUWIzL2RZdnpOTkVhWHljc3kzaEVvUEM2dXJRUzdjOS82dVN1WnBOcEpt?= =?utf-8?B?dDFjcGdEQ0lUS0lXVEczMWFaMTQzcFpDK29WSXM1dUFrRCtiY0tKV05XTjlH?= =?utf-8?B?aytDMG11MDhhemRKR3RSWDg5SFZiZlhsV25ya2x1VUJZaDVyK0Y2aUxoa3ha?= =?utf-8?B?SW1RdnVESGIxR2x4V0ZEYlVYcWUzcmtXWUlRKzVOMWhzRDl4cm1ZRE9SMXlS?= =?utf-8?B?WmM0bUlXaGlDcmN3UzZOeXdBbjRKOXVKa281Q00wc0Jzd2NZbmVKZGFST1hY?= =?utf-8?B?VENscDIxK2V2cGhxajV4S1FCaS9RK3RkYUFOZmNOU3RkVDlpT1NYNjNJeERi?= =?utf-8?Q?DYP1iCU/OBVLwGSX7wHv/ZFfpMAhPpSc=3D?=
X-Microsoft-Antispam-Message-Info: xTRp1pAQC/E9yQdIwe1K0LO4yCwRAtajnt2KQaCIgD0bE9SOnTU3/edaPHkpnVQKw7Z/x/gLRg6+qkaeIB0e4DCnYfCHYuJaMm4F94xsGGLrtcdo/EbCFl6IGUonCVlmOEEiIloKaJEhG4u/FGA8tOGzurod8toWEbsIZ2T/Qc44yMpavmGdlkZ3Fe6TBNLYV4VR8hRpH5Q1QsoCXrvAUQNtuZB7RVrk+ioopQjl7YY=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2133; 6:TQ823l5iFPN38mOp2Mk05HC4JkMKyk3XM77Ogtwlh7alEwUpz8rjPBK43U777riW/apI+COf/gZecT6LtTLPO++uJDGsXu15bJTgrnoS4wScFL1J+YvE33yK8wkG7NllMYgF4qa/GzmqI31gkgLZxjgcM0D6ghuXnEGWKBQL30XmwxtQeVYGI+hAbNC2X/lAqQmpj3EiwsVS35TtOEhgnxymXoTcoVVH3RAsZoT1SS/NlSsL40capV5Hs4KAwy3y6xJRRcgLVm5kMOx73OLQt7+4soWRdsF08GXwdhDHqMWbIIM7dHhGyT/5CI/SSFjN3iEVo634Ozp15fIWAlduuLUOw3VfsvIXOE2n5dUNa2lYBXVc3RG3Q/wlmsg8Lz87wL+54pwMycbH2C2pyqhaeyvSvMzwuogfMHyAUNv6Ef8VCg6/8p/NOqbIJRwyDgczzKutXwBumuFyG3FRsXvb9w==; 5:5OPWXVDaCJbe94giJ1eDMoxoXZfw0pKA4nKWjkZMQDhcW0YBcb0w9U8Z1VmKj4gkUCpxMqaPoegcxUVVsQN1lnhbGL5dzYmZTo26vI/PsA0LxQHWAnFuWFo9EfEILDJrPkCqNAgPke/eTvT3LcxskR30j/E1Ad2/wCBEy6C5lhM=; 24:NhnICkcov40HkA9CM+T7vDGKlPSfmDxf5IsalTuYIULbubV4ZM/MKg1ks/J0ZdhZClf8kU+Am5FdF3ClbVTtaUeFgbQ7Dye16tFmCmGPkHY=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2133; 7:hJ9hZd3rCHzxColWmaC7PKFtA10vyigCNYihES0AwEIrQ+3UeoQCQcrrM82+W+GaZRIxT/ZF32Xy2mWG0s2KvNwnMew9I1+LPs6dwj/GgTv4zYJvj8X6HleQVTExnqtPeT5co82SetJ0mgpTblzGStZnC6S3PHGAYBtOvuEmIToX32UQVFmnO4/8RUk/9YtEjNbSn+aODaZjjx18ksPZ2+aetpe9vLuwA4/KMB7T+IPI3/2tC2b6fL2jQo7CLYvG
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2018 21:59:01.3745 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7753983e-24cf-4a9d-3080-08d5942df310
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2133
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/5IJUC3FIDSV0gJVazONjD0Np5C0>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 27 Mar 2018 21:59:11 -0000

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/

Requirements Language
Please switch from 2119 to 8174

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.


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?

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.

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.

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 ?

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?

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?

Section 10
Shouldn't rfc5714 be referenced since the inequalities use the 
principles set forth in that rfc?


Typos/Editorial comments:
s/for a multi-homed prefixes/for multi-homed prefixes/

s/This document also provide/This document also provides/

indentation on second line:
       Cost (X,P)   - Cost of reaching the prefix P from prefix
                     originating node X.

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/

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.

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./

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"

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].

    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

s/If not, same /If not the same type/

   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.

   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.

    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 ...")

Figures 6 and 7, please add:
       P            - The multi-homed prefix being evaluated for
                      computing alternates

s/Section 3.5 and 3.6 of [RFC5286] describes/Sections 3.5 and 3.6 of 
[RFC5286] describe/

s/as defined in for IS-IS/as defined for IS-IS/

s/destined to D2 continue/destined to D2 continues/

s/ISIS/IS-IS/