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

"Aijun Wang" <wangaijun@tsinghua.org.cn> Fri, 16 August 2019 06:48 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 2E6A612002E for <lsr@ietfa.amsl.com>; Thu, 15 Aug 2019 23:48:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 KIQCUOx_BwMZ for <lsr@ietfa.amsl.com>; Thu, 15 Aug 2019 23:48:22 -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 C3E5E120013 for <lsr@ietf.org>; Thu, 15 Aug 2019 23:48:21 -0700 (PDT)
Received: from WangajPC (unknown [219.142.69.77]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 6E2CC663B8B; Fri, 16 Aug 2019 14:48:16 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: <tony.li@tony.li>, "'Robert Raszuk'" <robert@raszuk.net>
Cc: <lsr@ietf.org>
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>
In-Reply-To: <24D935ED-28C3-4A84-B42C-E429EC2D6FE8@tony.li>
Date: Fri, 16 Aug 2019 14:48:17 +0800
Message-ID: <00b601d553fe$9636a5a0$c2a3f0e0$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_00B7_01D55441.A459E5A0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdVTf1RxkES5Wh5dRD+DdwKqR7gZwQAfFDzw
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZVktVSkxOQkJCQkhCT09KTUNKWVdZKF lBSkxLS0o3V1ktWUFJV1kJDhceCFlBWTU0KTY6NyQpLjc#WQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OjY6KQw6PjlCKzwuHhwsMBFR OR9PChRVSlVKTk1OQkhDS0JCSktMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxMWVdZCAFZQUpLSk5LSjcG
X-HM-Tid: 0a6c992f19be9373kuws6e2cc663b8b
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3vshWgioozkXxp4WMcclTp96KPc>
Subject: [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: Fri, 16 Aug 2019 06:48:25 -0000

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

 

 

 

发件人: 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