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

Chris Bowers <cbowers@juniper.net> Sun, 21 June 2015 21:38 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 E0A2C1A88D8; Sun, 21 Jun 2015 14:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.099
X-Spam-Level: *
X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 KayTRMAf1fH0; Sun, 21 Jun 2015 14:38:12 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9DB1A88D4; Sun, 21 Jun 2015 14:38:12 -0700 (PDT)
Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by DM2PR0501MB1583.namprd05.prod.outlook.com (10.160.133.149) with Microsoft SMTP Server (TLS) id 15.1.190.14; Sun, 21 Jun 2015 21:38:07 +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; Sun, 21 Jun 2015 21:38:06 +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: AdCsIyHvkAdI4JvZScukBh5syZhVqAARUGPQ
Date: Sun, 21 Jun 2015 21:38:06 +0000
Message-ID: <BLUPR05MB29219107600DC4002B04D4AA9A20@BLUPR05MB292.namprd05.prod.outlook.com>
References: <327562D94EA7BF428CD805F338C31EF04FB4412B@nkgeml512-mbx.china.huawei.com>
In-Reply-To: <327562D94EA7BF428CD805F338C31EF04FB4412B@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: [24.55.7.123]
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1583; 3:OCLtkDTpFi+wjnudVwsBrpWkzK0fllOrcBBSLmAnUW1t5oDs56Ms/L39n0vBmVAMFDHDy+LzlCdOfxNj9p/Nm+rDKfj8K4xYxhLSIOpRpZAC9ztG/DGFkMlS4+lXPQIAW5ken9YpLYG5e+Dl2HDgQQ==; 10:9YaVi2m7/tSAgcbmui8RKJcpN1imVYmH1MH3ippq9ElgLU/yzjh+jDURfyXi/QLgQrPGduVBWYiR6bdltDyN8E6V82MAQVV2SXkUyAbvnEs=; 6:iIWXbeZmz1UCw6QqF4B8xvw4BWkVljTlSQz9fdEXONKNIwTD18gRKm/Y4bbFzXzN
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1583;
x-microsoft-antispam-prvs: <DM2PR0501MB158359ADCA3322D32AED9093A9A20@DM2PR0501MB1583.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520004)(3002001); SRVR:DM2PR0501MB1583; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1583;
x-forefront-prvs: 06141B80DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(5001770100001)(16236675004)(2501003)(76576001)(5003600100002)(5001960100002)(189998001)(33656002)(19617315012)(92566002)(5002640100001)(62966003)(19625215002)(77156002)(46102003)(87936001)(2656002)(54356999)(50986999)(2171001)(19580395003)(19580405001)(76176999)(74316001)(86362001)(40100003)(575784001)(19300405004)(66066001)(2900100001)(2950100001)(15975445007)(77096005)(230783001)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1583; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_BLUPR05MB29219107600DC4002B04D4AA9A20BLUPR05MB292namprd_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2015 21:38:06.3226 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1583
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/18d5cB1Z1ljHtL9mPJ8teCiZxi4>
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: Sun, 21 Jun 2015 21:38:16 -0000

Anil,


Thanks.  With respect to comment 1, I think your description is the expected behavior for block-ids.  The localroot for a given block will not have the same block-id as the rest of the nodes in the block.  This is taken into account in In_Common_Block() which not only compares block-ids, but also checks if either node is the localroot for the other node.  It was not initially obvious to me why it was done this way, but if you think about a topology where a given node is the localroot for two different blocks, it makes sense that the localroot can't share the same block-id with both blocks.  Therefore, the simplest thing is to have the localroot not share the block-id with either of the blocks.

I incorporated comment 2 in the github commit at:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/b5d1fe5354d44e9416f27b0fac1f99a66e54a79c

Chris

From: Anil Kumar S N (VRP Network BL) [mailto:anil.sn@huawei.com]
Sent: Sunday, June 21, 2015 8:07 AM
To: 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: [rtgwg] draft-ietf-rtgwg-mrt-frr-algorithm-03

HI Authors,

Comment 1:
In below topology if [R] is the local root of the topology, Block id of R is 0 and Block ID of all other nodes in the topology as per psudo-code, I feel it should be 0/1 for all.
When Assign_Block_ID is invoked, root gets the blockid 0, then since first DFS child local root is GADAG root block id is incremented to 1 and assigned, for all other DFS child block-id
Is assigned without incrementing it gets the value 1.

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



global_var: max_block_id

                 Assign_Block_ID(x, cur_block_id)
                   x.block_id = cur_block_id
                   foreach DFS child c of x
                      if (c.local_root is x)
                         max_block_id += 1
                         Assign_Block_ID(c, max_block_id)
                      else
                        Assign_Block_ID(c, cur_block_id)

                 max_block_id = 0
                 Assign_Block_ID(gadag_root, max_block_id)

Comment 2:  "This is necessary for the DFS in
   Lowpoint_Visit above, where the selection order of the interfaces to
   explore results in different trees."

This sentence can be changed,
"This is necessary for the DFS in  Lowpoint_Visit  as per section 4.3. , where the
selection order of the interfaces to explore results in different trees."

5.1.  Interface Ordering

   To ensure consistency in computation, all routers MUST order
   interfaces identically down to the set of links with the same metric
   to the same neighboring node.  This is necessary for the DFS in
   Lowpoint_Visit above, where the selection order of the interfaces to
   explore results in different trees.  Consistent interface ordering is
   also necessary for computing the GADAG, where the selection order of
   the interfaces to use to form ears can result in different GADAGs.
   It is also necessary for the topological sort described in
   Section 5.8, where different topological sort orderings can result in
   undirected links being added to the GADAG in different directions.

Thanks & Regards
Anil S N

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