Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

"Susan Hares" <> Fri, 16 August 2019 14:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4593D120219 for <>; Fri, 16 Aug 2019 07:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_DOS_OUTLOOK_TO_MX_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jGPPxXLXgMAT for <>; Fri, 16 Aug 2019 07:23:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94CC11201DE for <>; Fri, 16 Aug 2019 07:23:36 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'Aijun Wang'" <>, <>, "'Robert Raszuk'" <>
Cc: <>
References: <> <01a501d55338$945c2b40$bd1481c0$> <> <> <> <00b601d553fe$9636a5a0$c2a3f0e0$>
In-Reply-To: <00b601d553fe$9636a5a0$c2a3f0e0$>
Date: Fri, 16 Aug 2019 10:23:12 -0400
Message-ID: <00e801d5543e$234ad530$69e07f90$>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_00E9_01D5541C.9C393530"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMQRt967S9J4+Rd0yZBZEPR+UytfgF3VaMqAa5AiN4CAWRsrAJsDsDGApEglLikNsHAwA==
Content-Language: en-us
X-Antivirus: AVG (VPS 190816-2, 08/16/2019), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Lsr] =?utf-8?b?562U5aSNOiAgTFNSIFdvcmtpbmcgR3JvdXAgQWRvcHRpb24g?= =?utf-8?q?Call_for_=22Hierarchical_IS-IS=22_-_draft-li-lsr-isis-hierarchi?= =?utf-8?q?cal-isis-01?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Aug 2019 14:23:39 -0000



I’ll let Tony provide his answer to your question.   Let me provide an alternate topology that your example might fit into


 <> draft-hares-lsr-grid-ring-convergence-00.txt describes a problem with IGP convergence for the grid-ring phone topology that may be deployed in some 5G networks.  One way to solve the convergence problem is to provide an alternate fast convergence topology that uses hierarchy to provide shorter paths through the Grid portion of the grid-ring topology.  


Suppose in this topology, the regular IGP (ISIS) algorithm keeps the 2 level hierarchy.  


The alternate fast convergence algorithm uses a multiple level hierarchy in order to provide faster convergence.   The multiple levels provide “short-cut” paths for the IGP in a virtual topology in the Grid topology.  As discussions on this forum have indicated, the fast convergence topologies run in parallel with the normal IGP forwarding providing an alternate forwarding path.   If you would like me to explain how the hierarchy can provide faster convergence for a grid, I can provide that explanation to you (online or offline).    


Forwarding on the node needs to handle the multiple IGP routes.  Since  the fast convergence topologies provide early notification of forwarding problems in the normal IGP, the forward processing in the nodes might check this alternate topology for unknown routes.   Other ways of merging the two forwarding RIBs generated by the two IGPs also exist.  Since (per your example) R1 and R7 since the this link would be known to the regular IGP, the traffic could flow over this path. 


I hope this helps… 


Sue Hares 


PS – I would refresh the draft-hares-lsr-grid-ring-convergence-00.txt, but the draft submission seems to have a problem this morning.  This draft is still a rough draft. Some feedback I received indicates I should update sections.  



From: Lsr [] On Behalf Of Aijun Wang
Sent: Friday, August 16, 2019 2:48 AM
To:; 'Robert Raszuk'
Subject: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01


Hi, Tony:


Would you like to elaborate this in more detail to show how you design the control plane hierarchically but the traffic can be transported horizontally? Let’s consider the following graph:


If, as you stated,  we connect R1 and R7 via one link(although we will not do so, if we design the network hierarchically), how you flood the link information hierarchically but let the traffic between the two connected L1 area bypass the L2 area?



Best Regards.


Aijun Wang

China Telecom




发件人: [] 代表
发送时间: 2019年8月15日 23:37
收件人: Robert Raszuk
抄送:; Aijun Wang
主题: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01



Hi Robert,



> The hierarchical arrangement of the control plane does NOT imply that the data plane is necessarily hierarchical.  


Since Aijun posted his question I was trying to think of such model, but failed. 


While it is easy to envision this with DV protocols say BGP - do you have any pointer to a link state protocol architecture where data plane is non hierarchical (links do not belong to upper levels) while control plane used traverses multiple levels ? 



Consider any topology where two peer areas intersect.  At the intersection, traffic can transition between the areas without entering the parent level.


While I’m at it, I should also point out that the existence of hierarchy for the control plane does not mandate its use. This is another tool in the toolbox. Use the right tool for the job at hand.