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-boun...@ietf.org] On Behalf Of Aijun Wang Sent: Friday, August 16, 2019 2:48 AM To: tony...@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: 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-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tony...@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
