RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03

Chris Bowers <cbowers@juniper.net> Tue, 09 June 2015 18:58 UTC

Return-Path: <cbowers@juniper.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DE31A89E9; Tue, 9 Jun 2015 11:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 0sAl5ycCXJ-W; Tue, 9 Jun 2015 11:58:43 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F19A1A8980; Tue, 9 Jun 2015 11:58:43 -0700 (PDT)
Received: from BY1PR0501MB1576.namprd05.prod.outlook.com (25.160.203.15) by BY1PR0501MB1558.namprd05.prod.outlook.com (25.160.203.144) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 9 Jun 2015 18:58:41 +0000
Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BY1PR0501MB1576.namprd05.prod.outlook.com (25.160.203.15) with Microsoft SMTP Server (TLS) id 15.1.184.17; Tue, 9 Jun 2015 18:58:40 +0000
Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.01.0184.014; Tue, 9 Jun 2015 18:58:39 +0000
From: Chris Bowers <cbowers@juniper.net>
To: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>, Gábor Sándor Enyedi <gabor.sandor.enyedi@ericsson.com>, "Andras.Csaszar@ericsson.com" <Andras.Csaszar@ericsson.com>, Alia Atlas <akatlas@juniper.net>, "abishek@ece.arizona.edu" <abishek@ece.arizona.edu>
Subject: RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03
Thread-Topic: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03
Thread-Index: AdCifUFAAQ1JZlPETESLX6aiRMOLaAATVnnw
Date: Tue, 09 Jun 2015 18:58:39 +0000
Message-ID: <BLUPR05MB2925A1254FC0C5726AA7372A9BE0@BLUPR05MB292.namprd05.prod.outlook.com>
References: <327562D94EA7BF428CD805F338C31EF04FB436B4@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <327562D94EA7BF428CD805F338C31EF04FB436B4@nkgeml512-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [66.129.239.12]
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1576; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1558;
x-microsoft-antispam-prvs: <BY1PR0501MB157693A7F017609CDFF7B032A9BE0@BY1PR0501MB1576.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BY1PR0501MB1576; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1576;
x-forefront-prvs: 06022AA85F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51914003)(19609705001)(62966003)(76176999)(50986999)(54356999)(2900100001)(99286002)(2950100001)(77156002)(40100003)(74316001)(2656002)(66066001)(86362001)(19617315012)(87936001)(2501003)(122556002)(2171001)(19580405001)(102836002)(76576001)(5001770100001)(19300405004)(19625215002)(189998001)(92566002)(15975445007)(77096005)(19580395003)(16236675004)(5002640100001)(230783001)(5001960100002)(33656002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1576; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BLUPR05MB2925A1254FC0C5726AA7372A9BE0BLUPR05MB292namprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2015 18:58:39.6344 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1576
X-OriginatorOrg: juniper.net
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/sLXQyb-qzHsq14mN1BDQO4diPYI>
Cc: "rtgwg-owner@ietf.org" <rtgwg-owner@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 09 Jun 2015 18:58:48 -0000

Anil,

Thanks for the suggestion to clarify the use of root to mean gadag_root or spf_root in the pseudo-code, as well as the typo.  I made the changes on github.  The diff can be found at:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/ada619050ec9d773b7919a1c622f068d5a5a5e88
Tell me if you agree with these changes.

With respect to comment#3, if ((D is F) or (D.order_proxy is F)), then there are several cases to consider:

1) If the link from S to F is a cut-link,
                a) if this is a single cut-link between S and F, then there is no alternate
                b) if there are parallel cut-links between S and F, then one can, for example, ECMP across the remaining links, noting that there is no link protection.

2) if the link from S to F is not a cut-link, then at least one of the MRT next-hops for D (red or blue) will not be the same as the primary next-hop for D.  In which case, one should use the color that is not the primary next-hop as the alternate, noting that the alternate does not provide node protection.

I agree that the existing pseudo-code is not very clear here.  I am planning to update this part of the pseudo-code in the near future to make it clearer, but hopefully the explanation above suffices for the moment.

Chris


From: rtgwg [mailto:mailman-bounces@mail.ietf.org] On Behalf Of Anil Kumar S N (VRP Network BL)
Sent: Tuesday, June 09, 2015 1:27 AM
To: Gábor Sándor Enyedi; Andras.Csaszar@ericsson.com; Alia Atlas; Chris Bowers; abishek@ece.arizona.edu
Cc: rtgwg@ietf.org; rtgwg-owner@ietf.org
Subject: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03

Hi Authors,

As discussed before, Please find my review comments :

Comment 1: Can we rename parameter which is passed to these functions as real SPF root or GADAG root ?

   Run_DFS(node root)
   Run_Lowpoint(node root)
   Compute_Localroot(root, root)
   Construct_GADAG_via_Lowpoint(topology, root)
   Add_Undirected_Links(topo, root)
   Assign_Block_ID(root, max_block_id)
   Compute_MRT_NextHops(x, root)

Comment 2:  Here parenthesis are not matching, four '(' and five ')'.
           This must be typo mistake.


In_Common_Block(x, y)
  if ( (x.block_id is y.block_id))
       or (x is y.localroot) or (y is x.localroot) )
     return true
  return false


Comment 3:   Is it possible to rephrase "if an MRT doesn't use primary_intf"
What does the sentence "MRT doesn't use primary_intf" mean ? Dose it mean neither Red interface nor Blue interface is same as primary interface ?
What does the sentence "return that MRT color" means ?

Select_Alternates_Internal(S, D, F, primary_intf,
                           D_lower, D_higher, D_topo_order)

    //When D==F, we can do only link protection
    if ((D is F) or (D.order_proxy is F))
        if an MRT doesn't use primary_intf
            indicate alternate is not node-protecting
            return that MRT color


Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel