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

2019-08-19 Thread Susan Hares 
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-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, August 19, 2019 5:29 AM
To: Susan Hares
Cc: lsr@ietf.org; tony...@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  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-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 arrangem

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

2019-08-19 Thread Aijun Wang 
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  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-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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2019-08-16 Thread Susan Hares 
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

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

2019-08-16 Thread Aijun Wang 
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

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

2019-08-15 Thread Robert Raszuk 
Hi Tony,

> 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 ?

Thx,
R.

On Thu, Aug 15, 2019 at 4:40 PM  wrote:

>
> Hi Aijun,
>
> 1. The size of network is increasing, but it is becoming more flat. Is it
> the right direction to make the network more hierarchical?
>
>
>
> Well, given that we’re talking a link state protocol running SPF over a
> database in O(n log n) time, it’s pretty clear that we don’t want to scale
> the size of an area indefinitely. While modern processors are amazing
> (especially to those of us that started off with KHz 8080’s), it’s pretty
> clear that Moore’s law is over and that we cannot expect infinite compute
> power anytime in the future.  The alternative is to partition the network
> in some way.  Once partitioned, hierarchical arrangement seems like a
> natural fit. It’s been said that the only real tool that we have over scale
> is hierarchy.  Divide and conquer.
>
>
> 2. More hierarchical network means the traffic will also be traversed in
> hierarchical way, is it more efficient?
>
>
>
> The hierarchical arrangement of the control plane does NOT imply that the
> data plane is necessarily hierarchical.
>
>
> 3. Is there any other methods to scale out the IS-IS deployment?
>
>
>
> If you’ve been following along, Dynamic Flooding (
> https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03) allows us
> to address the limitations that we have with flooding, allowing us to scale
> the size of an area. However, it does not address the O(n log n) cost of
> SPF that will still ultimately bound the growth of areas and in turn
> necessitate more hierarchy.
>
> Regards,
> Tony
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2019-08-15 Thread tony . li 

Hi Aijun,

> 1. The size of network is increasing, but it is becoming more flat. Is it the 
> right direction to make the network more hierarchical? 


Well, given that we’re talking a link state protocol running SPF over a 
database in O(n log n) time, it’s pretty clear that we don’t want to scale the 
size of an area indefinitely. While modern processors are amazing (especially 
to those of us that started off with KHz 8080’s), it’s pretty clear that 
Moore’s law is over and that we cannot expect infinite compute power anytime in 
the future.  The alternative is to partition the network in some way.  Once 
partitioned, hierarchical arrangement seems like a natural fit. It’s been said 
that the only real tool that we have over scale is hierarchy.  Divide and 
conquer.


> 2. More hierarchical network means the traffic will also be traversed in 
> hierarchical way, is it more efficient?


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


> 3. Is there any other methods to scale out the IS-IS deployment?


If you’ve been following along, Dynamic Flooding 
(https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03 
) allows us to 
address the limitations that we have with flooding, allowing us to scale the 
size of an area. However, it does not address the O(n log n) cost of SPF that 
will still ultimately bound the growth of areas and in turn necessitate more 
hierarchy.

Regards,
Tony


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2019-08-15 Thread Acee Lindem (acee) 
Speaking as LSR WG Member:

Hi Aijun,
I agree that most deployments will not move to greater than two levels given 
that we’ve gone this many decades with two and the predominant underlay 
deployment is one level. However, there appears to be sufficient interest and 
couple with good technical work on the specification to move to the next stage 
and adopt this as a working group document.
Thanks,
Acee

From: Aijun Wang 
Date: Thursday, August 15, 2019 at 3:11 AM
To: Acee Lindem , "lsr@ietf.org" 
Subject: 答复: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

Some comments on this draft:
1. The size of network is increasing, but it is becoming more flat. Is it the 
right direction to make the network more hierarchical?
2. More hierarchical network means the traffic will also be traversed in 
hierarchical way, is it more efficient?
3. Is there any other methods to scale out the IS-IS deployment?


Best Regards.

Aijun Wang
China Telecom

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2019年8月12日 22:33
收件人: lsr@ietf.org
主题: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

This begins a two week LSR Working Group Adoption Poll for the "Hierarchical 
IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll will end at 12:00 AM 
UTC on August 27th, 2019. Please indicate your support of objection on this 
list prior to the end of the adoption poll.

Thanks,
Acee
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

2019-08-15 Thread Aijun Wang 
Some comments on this draft:

1. The size of network is increasing, but it is becoming more flat. Is it the 
right direction to make the network more hierarchical? 

2. More hierarchical network means the traffic will also be traversed in 
hierarchical way, is it more efficient?

3. Is there any other methods to scale out the IS-IS deployment?

 

 

Best Regards.

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem (acee)
发送时间: 2019年8月12日 22:33
收件人: lsr@ietf.org
主题: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

 

This begins a two week LSR Working Group Adoption Poll for the "Hierarchical 
IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll will end at 12:00 AM 
UTC on August 27th, 2019. Please indicate your support of objection on this 
list prior to the end of the adoption poll.

 

Thanks,

Acee

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr