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

"Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com> Thu, 18 June 2015 07:43 UTC

Return-Path: <anil.sn@huawei.com>
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 7EF661A1A4F; Thu, 18 Jun 2015 00:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 VqgDY1PvL4_l; Thu, 18 Jun 2015 00:43:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEE11A1A4B; Thu, 18 Jun 2015 00:43:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTX53725; Thu, 18 Jun 2015 07:43:05 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 18 Jun 2015 08:43:02 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.152]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Thu, 18 Jun 2015 15:42:55 +0800
From: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
To: Chris Bowers <cbowers@juniper.net>, 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: AdCifUFAAQ1JZlPETESLX6aiRMOLaAATVnnwACjeOWAAbkesEACHWMLQAH3w4bAAF3+MEA==
Date: Thu, 18 Jun 2015 07:42:54 +0000
Message-ID: <327562D94EA7BF428CD805F338C31EF04FB43F1F@nkgeml512-mbx.china.huawei.com>
References: <327562D94EA7BF428CD805F338C31EF04FB436B4@nkgeml512-mbx.china.huawei.com> <BLUPR05MB2925A1254FC0C5726AA7372A9BE0@BLUPR05MB292.namprd05.prod.outlook.com> <327562D94EA7BF428CD805F338C31EF04FB437FD@nkgeml512-mbx.china.huawei.com> <BLUPR05MB292BAD31261D2FB5D81E2F6A9BB0@BLUPR05MB292.namprd05.prod.outlook.com> <327562D94EA7BF428CD805F338C31EF04FB43CAF@nkgeml512-mbx.china.huawei.com> <BLUPR05MB2923CCD7881725EFCE3B138A9A60@BLUPR05MB292.namprd05.prod.outlook.com>
In-Reply-To: <BLUPR05MB2923CCD7881725EFCE3B138A9A60@BLUPR05MB292.namprd05.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.212.150]
Content-Type: multipart/alternative; boundary="_000_327562D94EA7BF428CD805F338C31EF04FB43F1Fnkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/6X21clVjKm45x9RAJhR7KZfL_uE>
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: Thu, 18 Jun 2015 07:43:11 -0000

Chris,

                I will go through the changes,  it will take some time to verify :)

I found one more things :

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


        In above 6 router topology, there are no ears.
        As per psudocode only GADAG root [R] will be assigned with IN_GADAG flag. A,B,C,D,E will not have the flag IN_GADAG set.

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: 18 June 2015 03:58
To: Anil Kumar S N (VRP Network BL); 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

Anil,

Thanks for pointing this out.  Construct_Ear() mentions identifying a cut-vertex in a comment, but doesn't actually set it explicitly.  I added it as below, as reflected in the github diff link.

Construct_Ear(x, Stack, intf, ear_type)
...
   if (ear_type is CHILD) and (cur_node is x)
      // x is a cut-vertex and the local root for
      // the block in which the ear is computed
      x.IS_CUT_VERTEX = true   <<< New line here
      localroot = x
   else

https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/6a92a3fe9f578af2566d0dbb042181cb22469c57

With respect to identifying cut-links, I'd like to propose the following changes to the Add_Undirected_Links() to have it deal better with parallel-links from the block root (cut-vertices or the GADAG root) to another node.   When adding undirected links to the GADAG, links connecting the block root to other nodes in that block need special handling because the topological order will not always give the right answer for links involving the block root.  There are three cases below.

case 1a) If the undirected link in question has another parallel link between the same two nodes that is already directed, then the direction of the undirected link can be inherited from the previously directed link.
case 1b) In the case of parallel cut links, we set all of the parallel links to both INCOMING and OUTGOING.
case 2) Otherwise, the undirected link in question is set to OUTGOING from the block root node.

With this version of Add_Undirected_Links(), a cut-link can be identified by the fact that it will be directed both INCOMING and OUTGOING in the GADAG.

I put proposed pseudo-code to replace figure 18 in the github diff below.

https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-algorithm/commit/5d5e5c9c74ef963195e29cb2e7b449c8884facd4

From: Anil Kumar S N (VRP Network BL) [mailto:anil.sn@huawei.com]
Sent: Monday, June 15, 2015 3:25 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 Chris,

                I couldn't find psudocode for indentifying and marking a link as cut-link and vertex as cut-vertex. Please correct me if I am wrong.

Thanks & Regards
Anil S N

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