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

Aijun:

It is certainly useful to introduce a new draft for a virtual topology solution for 5G/IPRAN topologies.   However, I awaited two things prior to releasing that draft:  a) additional feedback on the problem statement from some key people and b) the hierarchical ISIS adoption. 

As to virtual topologies … As you indicated virtual topologies are carried in IGPs MT-ISIS (RFC5120).   These virtual topologies could utilize the hierarchical ISIS extension.   These virtual topologies could also use the alternate fast convergence algorithms.    

I noticed that MT-ISIS MT IDs #3996-4096 are development, experimental, and proprietary features.  Perhaps deployment of the hierarchy for MT-ISIS might prove an good way for a network operations staff to get confidence that the hierarchy does not have an operational problem.     Alternatively,  you could define a standard MT topology which specific rules for hierarchical MT-ISIS.  Are you suggesting an standard MT topology be defined for hierarchical  ISIS?      

Susan Hares 

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, August 19, 2019 5:29 AM
To: Susan Hares
Cc: lsr@ietf.org; tony.li@tony.li; Robert Raszuk
Subject: Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

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

 <https://datatracker.ietf.org/doc/draft-hares-lsr-grid-ring-convergence/> 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