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

Aijun Wang <wangaijun@tsinghua.org.cn> Mon, 19 August 2019 09:29 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E5A1200B2 for <lsr@ietfa.amsl.com>; Mon, 19 Aug 2019 02:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3ySTt1sFL2Li for <lsr@ietfa.amsl.com>; Mon, 19 Aug 2019 02:29:06 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id 990401200E3 for <lsr@ietf.org>; Mon, 19 Aug 2019 02:29:03 -0700 (PDT)
Received: from [240.0.0.1] (unknown [185.189.254.86]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 632346610A0; Mon, 19 Aug 2019 17:28:56 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-339EE090-34CE-4650-B1FB-8418DD666A81
Mime-Version: 1.0 (1.0)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
X-Mailer: iPhone Mail (16F250)
In-Reply-To: <00e801d5543e$234ad530$69e07f90$@ndzh.com>
Date: Mon, 19 Aug 2019 17:28:52 +0800
Cc: tony.li@tony.li, Robert Raszuk <robert@raszuk.net>, lsr@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <BD241666-7BC1-477C-BA19-78EB7C6367CC@tsinghua.org.cn>
References: <8BAFFDB4-62B0-4018-966E-6861D89D0BD1@cisco.com> <01a501d55338$945c2b40$bd1481c0$@org.cn> <C90AD13E-1512-4373-9CF7-32BAD6D65EC6@tony.li> <CAOj+MMFNkVbgbN1v7Q_4PBfLVN=Me_whcR36Um-Eu_AgSDF4Xg@mail.gmail.com> <24D935ED-28C3-4A84-B42C-E429EC2D6FE8@tony.li> <00b601d553fe$9636a5a0$c2a3f0e0$@org.cn> <00e801d5543e$234ad530$69e07f90$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZVktVSkJLQkJCQkNPTE9KSUpKWVdZKF lBSkxLS0o3V1ktWUFJV1kJDhceCFlBWTU0KTY6NyQpLjc#WQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OSI6AQw4STlDPzEjFzMyPQ88 KShPCkNVSlVKTk1NSUtNQk9JTUNMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKQ05VSkNCVUlOT1VDTVlXWQgBWUFJTk9JSDcG
X-HM-Tid: 0a6ca93545589373kuws632346610a0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/kWgS69kBimb9Z7gkmDYrs_EI-64>
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-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Aug 2019 09:29:09 -0000

Hi, Susan:
It seems better to introduce one new draft to introduce your “virtual topology” solution, especially the control plane and forward plane behavior, how it interact with the deployed level 1/2 solutions.

I think to improve the convergence performance in large network such as 5G/IP RAN network is one attractive topic but we need to select/make the solutions being deployed easily and smoothly.

Aijun Wang
China Telecom

> On Aug 16, 2019, at 22:23, Susan Hares <shares@ndzh.com> wrote:
> 
> Ajun:
>  
> 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 [mailto:lsr-bounces@ietf.org] On Behalf Of Aijun Wang
> Sent: Friday, August 16, 2019 2:48 AM
> To: tony.li@tony.li; 'Robert Raszuk'
> Cc: lsr@ietf.org
> 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:
>  
> <image001.png>
> 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
>  
>  
>  
> 发件人: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] 代表 tony.li@tony.li
> 发送时间: 2019年8月15日 23:37
> 收件人: Robert Raszuk
> 抄送: lsr@ietf.org; 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.
>  
> Tony
>  
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr