Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread tony . li


> so it's party like it's 1999, seems the peer group leader election gets 
> rediscovered ;-)  Interesting old new problems, interesting old new attack 
> vectors like https://ieeexplore.ieee.org/document/822780/ 
> 

No argument there.  There are no new problems or solutions.  Just us 
rediscovering the problems and approaches that others have used before.

That said, the solutions still need to be applied.  That is, after all, 
engineering.

Preferably in a Little Red Corvette.

Tony


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


Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Tony Przygienda
On Mon, Aug 27, 2018 at 9:41 AM Huaimo Chen  wrote:

> Hi Robert,
>
>
>
> >Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> Today’s DR or DIS election is local to a special interface/network such as
> a broadcast interface. Leader election in a network is global. Every node
> in the network depends on it (its flooding topology). These two seems
> different.
>
>
>

so it's party like it's 1999, seems the peer group leader election gets
rediscovered ;-)  Interesting old new problems, interesting old new attack
vectors like https://ieeexplore.ieee.org/document/822780/

 tony

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


Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Robert Raszuk
> draft-cc-ospf-flooding-reduction-02 allows operators to select
distributed mode, centralized one or static one smoothly.

Aside from static approach can you summarize in purely technical points
advantages your draft proposes over draft-li-dynamic-flooding-05 ?

Many thx,
R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen  wrote:

> Hi Robert,
>
>
>
> >Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> Today’s DR or DIS election is local to a special interface/network such as
> a broadcast interface. Leader election in a network is global. Every node
> in the network depends on it (its flooding topology). These two seems
> different.
>
>
>
> >Btw I don't think there is any problem here ... The text added to -05
> version allows very seamless choice of centralized vs distributed topology
> computation by signalling either zero or non zero value in the added to
> version -05 area leader sub-tlv.
>
> >
>
> >In other words I don't see any problem or room for debate .. adopting and
> implementing -05 allows use of centralized or distributed optimal flooding
> computation at the operator's discretion.
>
>
>
> draft-cc-ospf-flooding-reduction-02 allows operators to select
> distributed mode, centralized one or static one smoothly.
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Monday, August 27, 2018 11:31 AM
> *To:* Huaimo Chen 
> *Cc:* tony...@tony.li; lsr@ietf.org; Jeff Tantsura <
> jefftant.i...@gmail.com>; Acee Lindem (acee)  org>; Peter Psenak ; Tony Przygienda <
> tonysi...@gmail.com>
> *Subject:* Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
>
>
> Hi Huaimo,
>
>
>
> > Introducing centralized feature into IGP will break IGP's distributed
> nature
>
>
>
> That clearly proves that word "centralized" has been significantly
> overloaded here.  To many indeed "centralized" means a controller (like
> OpenFlow or SDN) and that such device added to a network is to push
> information - typically 1RU linux blade -  here optimized flooding graph.
> But this never was the plan with this proposal from its start ie. -00
> version.
>
>
>
> Centralized means that optimized flooding graph comes from single
> redundant node.
>
>
>
> Leader election happens automatically and procedures for that are to be
> vastly similar to today's DR or DIS election. So with this in mind one may
> observe that both OSPF and ISIS are pretty centralized on multiaccess
> networks today :)
>
>
>
> To your point of multi-vendor networks true - and that is precisely why
> upgrade network wide to a release containing consistent algorithm from more
> then a single vendor (and even for single vendor) is practically a very
> time consuming and difficult process.
>
>
>
> Btw I don't think there is any problem here ... The text added to -05
> version allows very seamless choice of centralized vs distributed topology
> computation by signalling either zero or non zero value in the added to
> version -05 area leader sub-tlv.
>
>
>
> In other words I don't see any problem or room for debate .. adopting and
> implementing -05 allows use of centralized or distributed optimal flooding
> computation at the operator's discretion.
>
>
>
> Thx,
>
> R.
>
>
>
> On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen 
> wrote:
>
> >> I think distributed is more practical too.
> >I would appreciate more detailed insights as to why you (and others) feel
> this way.  It is not at all obvious to me.
> IGP is distributed in nature. The distributed computation of flooding
> topology like distributed SPF will keep IGP still distributed in nature.
> Introducing centralized feature into IGP will break IGP's distributed
> nature, which may cause some issues/problems.
>
> >> For computing routes, we have been using distributed SPF on every node
> for many years.
> >True, but that algorithm is (and was) very well known and a fixed
> algorithm that would clearly solve the problem at the time. If we were in a
> similar situation, where we were ready to set an algorithm in >concrete, I
> might well agree, but it’s quite clear that we are NOT at that point yet.
> We will need to experiment and modify algorithms, and as discussed, that’s
> easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will
> we be allowed to do experiments on their network?
> After an algorithm is determined/selected, will it be changed to another
> algorithm in a short time?
>
> >> In fact, we may not need to run the exact algorithm on every node. As
> long as the algorithms running on different nodes generate the same result,
> that would work.
> >Insuring a globally consistent result without running the exact same
> algorithm on the exact same data will be quite a trick.  Debugging
> distributed 

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread tony . li
> Today’s DR or DIS election is local to a special interface/network such as a 
> broadcast interface. Leader election in a network is global. Every node in 
> the network depends on it (its flooding topology). These two seems different.


Hmm….  Ethernet is not ‘special’.   Pretty much all that we have today.  :-)

If DR/DIS election fails, then there’s likely to be a failure in flooding.  
Anything transiting that network is likely to be mis-routed. Seems not very 
different to me.  The phone will ring regardless.

Tony

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


Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Huaimo Chen
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen 
Cc: tony...@tony.li; lsr@ietf.org; Jeff Tantsura ; 
Acee Lindem (acee) ; Peter Psenak 
; Tony Przygienda 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded 
here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) 
and that such device added to a network is to push information - typically 1RU 
linux blade -  here optimized flooding graph. But this never was the plan with 
this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant 
node.

Leader election happens automatically and procedures for that are to be vastly 
similar to today's DR or DIS election. So with this in mind one may observe 
that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade 
network wide to a release containing consistent algorithm from more then a 
single vendor (and even for single vendor) is practically a very time consuming 
and difficult process.

Btw I don't think there is any problem here ... The text added to -05 version 
allows very seamless choice of centralized vs distributed topology computation 
by signalling either zero or non zero value in the added to version -05 area 
leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and 
implementing -05 allows use of centralized or distributed optimal flooding 
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
>> I think distributed is more practical too.
>I would appreciate more detailed insights as to why you (and others) feel this 
>way.  It is not at all obvious to me.
IGP is distributed in nature. The distributed computation of flooding topology 
like distributed SPF will keep IGP still distributed in nature. Introducing 
centralized feature into IGP will break IGP's distributed nature, which may 
cause some issues/problems.

>> For computing routes, we have been using distributed SPF on every node for 
>> many years.
>True, but that algorithm is (and was) very well known and a fixed algorithm 
>that would clearly solve the problem at the time. If we were in a similar 
>situation, where we were ready to set an algorithm in >concrete, I might well 
>agree, but it’s quite clear that we are NOT at that point yet.  We will need 
>to experiment and modify algorithms, and as discussed, that’s easier with a 
>centralized approach.
After flooding reduction is deployed in an operational (ISP) network, will we 
be allowed to do experiments on their network?
After an algorithm is determined/selected, will it be changed to another 
algorithm in a short time?

>> In fact, we may not need to run the exact algorithm on every node. As long 
>> as the algorithms running on different nodes generate the same result, that 
>> would work.
>Insuring a globally consistent result without running the exact same algorithm 
>on the exact same data will be quite a trick.  Debugging distributed problems 
>at scale is already a hard problem.  Having >different algorithms in different 
>locations would add another order of magnitude in difficulty.  No thank you.
In some existing networks, some nodes run IGPs from one vendor, some other 
nodes run IGPs from another vendor, and so on. Some may use normal SPF, some 
others may use incremental SPF. It seems that we have had these cases for many 
years.
>Tony

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread tony . li

Hi Huaimo,


> After flooding reduction is deployed in an operational (ISP) network, will we 
> be allowed to do experiments on their network? 


Some may well permit it.  Certainly in lab scenarios they may be very willing.  
It all depends on their motivation to achieve improvements.

It should be remembered that we are where we are today because some people were 
willing to work towards better technology and understood that there would be 
issues while we worked out issues with implementations. All protocols, 
features, and implementations have growing pains. We are where we are because 
we work through them.


> After an algorithm is determined/selected, will it be changed to another 
> algorithm in a short time? 


Possibly. Someone may have an insight that produces theoretical breakthrough 
and gives us a completely different algorithm. Or, more likely, someone 
discovers a catastrophic bug in an algorithm and moves to fix it.


> In some existing networks, some nodes run IGPs from one vendor, some other 
> nodes run IGPs from another vendor, and so on. Some may use normal SPF, some 
> others may use incremental SPF. It seems that we have had these cases for 
> many years. 


I’m unaware of anyone trying to get EIGRP to interoperate with IS-IS at the 
protocol level.  ;-)

I’m also unaware of anyone trying to implement anything other than SPF.

And that’s what I think you’re proposing…

Tony


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


Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Robert Raszuk
Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed
nature

That clearly proves that word "centralized" has been significantly
overloaded here.  To many indeed "centralized" means a controller (like
OpenFlow or SDN) and that such device added to a network is to push
information - typically 1RU linux blade -  here optimized flooding graph.
But this never was the plan with this proposal from its start ie. -00
version.

Centralized means that optimized flooding graph comes from single redundant
node.

Leader election happens automatically and procedures for that are to be
vastly similar to today's DR or DIS election. So with this in mind one may
observe that both OSPF and ISIS are pretty centralized on multiaccess
networks today :)

To your point of multi-vendor networks true - and that is precisely why
upgrade network wide to a release containing consistent algorithm from more
then a single vendor (and even for single vendor) is practically a very
time consuming and difficult process.

Btw I don't think there is any problem here ... The text added to -05
version allows very seamless choice of centralized vs distributed topology
computation by signalling either zero or non zero value in the added to
version -05 area leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and
implementing -05 allows use of centralized or distributed optimal flooding
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen  wrote:

> >> I think distributed is more practical too.
> >I would appreciate more detailed insights as to why you (and others) feel
> this way.  It is not at all obvious to me.
> IGP is distributed in nature. The distributed computation of flooding
> topology like distributed SPF will keep IGP still distributed in nature.
> Introducing centralized feature into IGP will break IGP's distributed
> nature, which may cause some issues/problems.
>
> >> For computing routes, we have been using distributed SPF on every node
> for many years.
> >True, but that algorithm is (and was) very well known and a fixed
> algorithm that would clearly solve the problem at the time. If we were in a
> similar situation, where we were ready to set an algorithm in >concrete, I
> might well agree, but it’s quite clear that we are NOT at that point yet.
> We will need to experiment and modify algorithms, and as discussed, that’s
> easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will
> we be allowed to do experiments on their network?
> After an algorithm is determined/selected, will it be changed to another
> algorithm in a short time?
>
> >> In fact, we may not need to run the exact algorithm on every node. As
> long as the algorithms running on different nodes generate the same result,
> that would work.
> >Insuring a globally consistent result without running the exact same
> algorithm on the exact same data will be quite a trick.  Debugging
> distributed problems at scale is already a hard problem.  Having >different
> algorithms in different locations would add another order of magnitude in
> difficulty.  No thank you.
> In some existing networks, some nodes run IGPs from one vendor, some other
> nodes run IGPs from another vendor, and so on. Some may use normal SPF,
> some others may use incremental SPF. It seems that we have had these cases
> for many years.
> >Tony
>
> Best Regards,
> Huaimo
> ___
> 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 Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Huaimo Chen
>> I think distributed is more practical too. 
>I would appreciate more detailed insights as to why you (and others) feel this 
>way.  It is not at all obvious to me.
IGP is distributed in nature. The distributed computation of flooding topology 
like distributed SPF will keep IGP still distributed in nature. Introducing 
centralized feature into IGP will break IGP's distributed nature, which may 
cause some issues/problems. 

>> For computing routes, we have been using distributed SPF on every node for 
>> many years.
>True, but that algorithm is (and was) very well known and a fixed algorithm 
>that would clearly solve the problem at the time. If we were in a similar 
>situation, where we were ready to set an algorithm in >concrete, I might well 
>agree, but it’s quite clear that we are NOT at that point yet.  We will need 
>to experiment and modify algorithms, and as discussed, that’s easier with a 
>centralized approach.
After flooding reduction is deployed in an operational (ISP) network, will we 
be allowed to do experiments on their network? 
After an algorithm is determined/selected, will it be changed to another 
algorithm in a short time? 

>> In fact, we may not need to run the exact algorithm on every node. As long 
>> as the algorithms running on different nodes generate the same result, that 
>> would work. 
>Insuring a globally consistent result without running the exact same algorithm 
>on the exact same data will be quite a trick.  Debugging distributed problems 
>at scale is already a hard problem.  Having >different algorithms in different 
>locations would add another order of magnitude in difficulty.  No thank you.
In some existing networks, some nodes run IGPs from one vendor, some other 
nodes run IGPs from another vendor, and so on. Some may use normal SPF, some 
others may use incremental SPF. It seems that we have had these cases for many 
years. 
>Tony

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr


[Lsr] I-D Action: draft-ietf-ospf-ospfv2-hbit-06.txt

2018-08-27 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : H-bit Support for OSPFv2
Authors : Keyur Patel
  Padma Pillay-Esnault
  Manish Bhardwaj
  Serpil Bayraktar
Filename: draft-ietf-ospf-ospfv2-hbit-06.txt
Pages   : 8
Date: 2018-08-27

Abstract:
   OSPFv3 defines an option bit for router-LSAs known as the R-bit in
   RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
   OSPF topology flooding, however it will not be used as a transit
   router.  In such cases, other routers in the OSPFv3 routing domain
   only install routes to allow local traffic delivery.  This document
   defines the H-bit functionality to prevent other OSPFv2 routers from
   using the router for transit traffic in OSPFv2 routing domains as
   described in RFC 2328.  This document updates RFC 2328.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-ospfv2-hbit-06
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv2-hbit-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv2-hbit-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Huaimo Chen
Hi Chris, Peter and Everyone,

>-Original Message-
>From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>Sent: Monday, August 27, 2018 8:22 AM
>To: Christian Hopps ; Tony Li 
>Cc: lsr@ietf.org; Jeff Tantsura ; Acee Lindem (acee) 
>; Tony Przygienda 
>Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward>
>
>Chris and All,
>
>On 27/08/18 14:10 , Christian Hopps wrote:
>>
>>
>>> On Aug 24, 2018, at 12:29 PM, tony...@tony.li wrote:
>>>
>>> Being distributed would be very nice.  However, that implies that all nodes 
>>> are going to get to the exact same solution. Which implies that they all 
>>> must execute the same algorithm, presumably with >the same inputs.
>>>
>>> That’s all well and good, but we don’t have an algorithm to really put on 
>>> the table yet.  We need experience with one.  We know we want to tweak 
>>> things based on biconnectivity, performance, and degree because doing it 
>>> right day one seems unlikely.  Changing algorithms is going to be VERY 
>>> painful if it’s distributed.
>>>
>>> However, if it’s centralized, it’s completely trivial.
>>
>> I find this reasoning quite compelling.
>
>I would leave the door open for both and not limit the solution to one or the 
>other.
>
>As an example, draft-li-dynamic-flooding-05 supports both centralized and 
>distributed mode of operation.
>

draft-cc-ospf-flooding-reduction-02 supports operations on three modes 
including distributed mode and centralized one. 

Best Regards,
Huaimo

>thanks,
>Peter


>>
>> Thanks,
>> Chris.
>>

___
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 Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Peter Psenak

Chris and All,

On 27/08/18 14:10 , Christian Hopps wrote:




On Aug 24, 2018, at 12:29 PM, tony...@tony.li wrote:

Being distributed would be very nice.  However, that implies that all nodes are 
going to get to the exact same solution. Which implies that they all must 
execute the same algorithm, presumably with the same inputs.

That’s all well and good, but we don’t have an algorithm to really put on the 
table yet.  We need experience with one.  We know we want to tweak things based 
on biconnectivity, performance, and degree because doing it right day one seems 
unlikely.  Changing algorithms is going to be VERY painful if it’s distributed.

However, if it’s centralized, it’s completely trivial.


I find this reasoning quite compelling.


I would leave the door open for both and not limit the solution to one 
or the other.


As an example, draft-li-dynamic-flooding-05 supports both centralized 
and distributed mode of operation.


thanks,
Peter




Thanks,
Chris.



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


Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

2018-08-27 Thread Christian Hopps


> On Aug 24, 2018, at 12:29 PM, tony...@tony.li wrote:
> 
> Being distributed would be very nice.  However, that implies that all nodes 
> are going to get to the exact same solution. Which implies that they all must 
> execute the same algorithm, presumably with the same inputs.
> 
> That’s all well and good, but we don’t have an algorithm to really put on the 
> table yet.  We need experience with one.  We know we want to tweak things 
> based on biconnectivity, performance, and degree because doing it right day 
> one seems unlikely.  Changing algorithms is going to be VERY painful if it’s 
> distributed.
> 
> However, if it’s centralized, it’s completely trivial.

I find this reasoning quite compelling.

Thanks,
Chris.


signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr