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

Chris Bowers <cbowers@juniper.net> Fri, 26 June 2015 01:50 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 1E0B21B3144; Thu, 25 Jun 2015 18:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level:
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, J_CHICKENPOX_46=0.6, 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 DwD9kb_Im393; Thu, 25 Jun 2015 18:50:03 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577471A1A38; Thu, 25 Jun 2015 18:50:03 -0700 (PDT)
Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BY1PR0501MB1574.namprd05.prod.outlook.com (10.160.203.148) with Microsoft SMTP Server (TLS) id 15.1.201.16; Fri, 26 Jun 2015 01:50:00 +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.0195.005; Fri, 26 Jun 2015 01:50:00 +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: AdCsIyHvkAdI4JvZScukBh5syZhVqAARUGPQAE6/CrAAB3bpkAADC8lgAF3tQFAAGYNB4A==
Date: Fri, 26 Jun 2015 01:49:59 +0000
Message-ID: <BLUPR05MB292FAC8B9B78B335C89320FA9AD0@BLUPR05MB292.namprd05.prod.outlook.com>
References: <327562D94EA7BF428CD805F338C31EF04FB4412B@nkgeml512-mbx.china.huawei.com> <BLUPR05MB29219107600DC4002B04D4AA9A20@BLUPR05MB292.namprd05.prod.outlook.com> <327562D94EA7BF428CD805F338C31EF04FB44296@nkgeml512-mbx.china.huawei.com> <BLUPR05MB292587A4F3860411C9D4F72A9A00@BLUPR05MB292.namprd05.prod.outlook.com> <327562D94EA7BF428CD805F338C31EF04FB4450E@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <327562D94EA7BF428CD805F338C31EF04FB4450E@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-exchange-diagnostics: 1; BY1PR0501MB1574; 5:Gg7L6hFSvoMkwXUtE0oy36RgSHOcWojEqjuyeIiwTJaT/PtIvtNzD/0VCOL0nB3Gej52sp0asENZkOMhobGH6BXBK3Bnq2aj5/o5c/uTtTy6PyC0do6VNYGW/GmTHgh921ie9zaTWgW++gDyJTsYiA==; 24:woeh3bSyEXrJwRbhCi7jYZNdRm9pf2NQC1n4nrV6t/N4OjcvyDuSP8aJzoKm6OGkiGR0yZpewQW/rVjfJNTnZObd/RyOtAOH+YL1KD7/J/M=; 20:M0G5cm3ZYeqeN+Na9iNk22WdrZYitnoTR0X7WOycYcrMQNPEzoqeIt8Rug3N/hhg3Zq+lMR2n5M0Zy9bpuwG/Q==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1574;
x-microsoft-antispam-prvs: <BY1PR0501MB15747A144254D8403897B9D5A9AD0@BY1PR0501MB1574.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY1PR0501MB1574; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1574;
x-forefront-prvs: 0619D53754
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(87936001)(2656002)(46102003)(93886004)(230783001)(77156002)(19580395003)(19580405001)(2171001)(5003600100002)(92566002)(74316001)(19625215002)(86362001)(33656002)(99286002)(54356999)(50986999)(76176999)(19300405004)(40100003)(5002640100001)(16236675004)(66066001)(62966003)(2950100001)(76576001)(19609705001)(122556002)(189998001)(5001770100001)(2900100001)(77096005)(15975445007)(2501003)(102836002)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1574; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BLUPR05MB292FAC8B9B78B335C89320FA9AD0BLUPR05MB292namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2015 01:49:59.8154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1574
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/eCSYQSatAwpG6nFqMyv-GIbW_DA>
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: <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: Fri, 26 Jun 2015 01:50:09 -0000

Anil,

I think the pseudocode will work correctly as currently written.   It is safe to store the next-hops for spf_root to reach min_node immediately after removing min_node, the heap element with the lowest value of spf_metric, from spf_heap.  The reasoning is described below.

spf_heap starts out with just spf_root in it, and spf_root gets removed the first time that the line min_node = remove_lowest(spf_heap) is hit.  So now spf_heap is empty and the only way that a node gets put into spf_heap is with the line: insert_or_update(spf_heap, intf.remote_node).  Immediately before this line, intf.remote_node.next_hops are either created based on intf, or inherited from min_node.  Either way, a given node G can't get into spf_heap without having its next_hops value set to some value.  The G.next_hops are the interfaces on spf_root to reach G on the shortest path yet explored.  As the SPF algorithm runs, the value of G.next_hops can be changed, either as a new shortest path is explored, or as an equal cost path is explored.

When it comes time to remove G from spf_heap (via min_node = remove_lowest(spf_heap) ), G has the lowest spf_metric of any node remaining on the heap.  There is no chance that any paths explored in the SPF algorithm after G is removed from the heap will result in changing G.next_hops because any such path would necessarily have an spf_metric higher than G.spf_metric.  Therefore, it is safe to call Store_Results(G, direction) after G is removed from spf_heap, because G.next_hops won't get changed anymore.

The last node on spf_heap (the one with the highest value of spf_metric in the topology) will get removed and Store_Results will get called, so last node will be completely processed.  The algorithm will go through the motions of exploring all of the interfaces of last node, but it won't result in any new remote nodes being added to spf_heap.  So "while (spf_heap is not empty)" will terminate the next time around.

I hope this makes sense.

Chris


From: Anil Kumar S N (VRP Network BL) [mailto:anil.sn@huawei.com]
Sent: Thursday, June 25, 2015 7:54 AM
To: Anil Kumar S N (VRP Network BL); Chris Bowers; Gábor Sándor Enyedi; Andras.Csaszar@ericsson.com; Alia Atlas; abishek@ece.arizona.edu
Cc: rtgwg@ietf.org; rtgwg-owner@ietf.org
Subject: RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03

Chris,

                Store_Results should be called after nexthop is updated, The last node processed and its nexthop is not updated I feel.
I might be wrong, Please correct me if I am wrong.

Base :

SPF_No_Traverse_Block_Root(spf_root, block_root, direction)
   Initialize spf_heap to empty
   Initialize nodes' spf_metric to infinity and next_hops to empty
   spf_root.spf_metric = 0
   insert(spf_heap, spf_root)
   while (spf_heap is not empty)
       min_node = remove_lowest(spf_heap)
       Store_Results(min_node, direction)
       if ((min_node is spf_root) or (min_node is not block_root))
          foreach interface intf of min_node
                if ( ( ((direction is FORWARD) and intf.OUTGOING) or
                       ((direction is REVERSE) and intf.INCOMING) )
                       and In_Common_Block(spf_root, intf.remote_node) )
                path_metric = min_node.spf_metric + intf.metric
                if path_metric < intf.remote_node.spf_metric
                   intf.remote_node.spf_metric = path_metric
                   if min_node is spf_root
                     intf.remote_node.next_hops = make_list(intf)
                   else
                     intf.remote_node.next_hops = min_node.next_hops
                   insert_or_update(spf_heap, intf.remote_node)
                else if path_metric is intf.remote_node.spf_metric
                   if min_node is spf_root
                      add_to_list(intf.remote_node.next_hops, intf)
                   else
                      add_list_to_list(intf.remote_node.next_hops,
                                       min_node.next_hops)


Modified :

SPF_No_Traverse_Block_Root(spf_root, block_root, direction)
   Initialize spf_heap to empty
   Initialize nodes' spf_metric to infinity and next_hops to empty
   spf_root.spf_metric = 0
   insert(spf_heap, spf_root)
   while (spf_heap is not empty)
       min_node = remove_lowest(spf_heap)
       Store_Results(min_node, direction)
       if ((min_node is spf_root) or (min_node is not block_root))
          foreach interface intf of min_node
                if ( ( ((direction is FORWARD) and intf.OUTGOING) or
                       ((direction is REVERSE) and intf.INCOMING) )
                       and In_Common_Block(spf_root, intf.remote_node) )
                path_metric = min_node.spf_metric + intf.metric
                if path_metric < intf.remote_node.spf_metric
                   intf.remote_node.spf_metric = path_metric
                   if min_node is spf_root
                     intf.remote_node.next_hops = make_list(intf)
                   else
                     intf.remote_node.next_hops = min_node.next_hops
                   insert_or_update(spf_heap, intf.remote_node)
                else if path_metric is intf.remote_node.spf_metric
                   if min_node is spf_root
                      add_to_list(intf.remote_node.next_hops, intf)
                   else
                      add_list_to_list(intf.remote_node.next_hops,
                                       min_node.next_hops)
       Store_Results(min_node, direction)


Thanks & Regards
Anil S N

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


From: Anil Kumar S N (VRP Network BL)
Sent: 23 June 2015 21:29
To: 'Chris Bowers'; Gábor Sándor Enyedi; Andras.Csaszar@ericsson.com<mailto:Andras.Csaszar@ericsson.com>; Alia Atlas; abishek@ece.arizona.edu<mailto:abishek@ece.arizona.edu>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-owner@ietf.org<mailto:rtgwg-owner@ietf.org>
Subject: RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03

Chris,

                Yes it definitely makes sense,  thanks I should have thought about this.

Thanks & Regards
Anil S N

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


From: Chris Bowers [mailto:cbowers@juniper.net]
Sent: 23 June 2015 20:19
To: Anil Kumar S N (VRP Network BL); Gábor Sándor Enyedi; Andras.Csaszar@ericsson.com<mailto:Andras.Csaszar@ericsson.com>; Alia Atlas; abishek@ece.arizona.edu<mailto:abishek@ece.arizona.edu>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-owner@ietf.org<mailto:rtgwg-owner@ietf.org>
Subject: RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03

Anil,

Reusing the topology below, R (the gadag_root) will have block_id=0 while A,B,C,D and E will have block_id=1. so the first OR'd condition in In_Common_Block(R,y) will always be false when determining if R is in the same block as A,B,C,D, or E.  The third OR'd condition will also be false because R.localroot = None.  However, the second OR'd condition will be true because R = B.localroot (for example), returning true for In_Common_Block(R,B). Does this make sense?

Chris
             [E]----|
            (5,0)   |
              |     |
              |     |
             [R]   [D]---[C]
            (0,0) (4,0) (3,0)
              |           |
              |           |
             [A]---------[B]
            (1,0)       (2,0)

From: Anil Kumar S N (VRP Network BL) [mailto:anil.sn@huawei.com]
Sent: Tuesday, June 23, 2015 6:04 AM
To: Chris Bowers; Gábor Sándor Enyedi; Andras.Csaszar@ericsson.com<mailto:Andras.Csaszar@ericsson.com>; Alia Atlas; abishek@ece.arizona.edu<mailto:abishek@ece.arizona.edu>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-owner@ietf.org<mailto:rtgwg-owner@ietf.org>
Subject: RE: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03

Hi Chirs,

gadag_root.localroot will remain as  None at the end of algorithm and gadag_root.block_id will be 0 (rest of the nodes in the block will be 1 higher than gadag_root.block_id)
Below psudocode will return false while comparing a node in a block and gadag_root.

                Please correct me if I am wrong.

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

Thanks & Regards
Anil S N

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