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

2018-09-04 Thread John E Drake
Cc: tony...@tony.li; Acee Lindem (acee) ; lsr@ietf.org; Jeff Tantsura ; Tony Przygienda ; Peter Psenak Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Hi John, Two drafts are presented in just two IETFs. For centralized mode and distributed one, one very important part

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

2018-09-04 Thread Huaimo Chen
Psenak Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Hi, I think we have circled back to the implicit point of my original email, viz, why do we need two drafts that solve the same problem in more or less the same way, especially given that one is much more robust and complete

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

2018-09-04 Thread John E Drake
: Tuesday, September 4, 2018 11:24 AM To: John E Drake ; Robert Raszuk Cc: tony...@tony.li; Acee Lindem (acee) ; lsr@ietf.org; Jeff Tantsura ; Tony Przygienda ; Peter Psenak Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Hi John, See my comments inline below. Best

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

2018-09-04 Thread Huaimo Chen
rg>; Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Tony Przygienda mailto:tonysi...@gmail.com>>; Peter Psenak mailto:ppse...@cisco.com>> Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Hi Robert, >> draft-cc-ospf-flooding-reduction-02 allows oper

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

2018-08-30 Thread John E Drake
On Behalf Of Huaimo Chen Sent: Thursday, August 30, 2018 11:01 AM To: Robert Raszuk Cc: tony...@tony.li; Acee Lindem (acee) ; lsr@ietf.org; Jeff Tantsura ; Tony Przygienda ; Peter Psenak Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Hi Robert, >> draft-cc-ospf-fl

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

2018-08-30 Thread Huaimo Chen
m (acee) mailto:40cisco@dmarc.ietf.org>>; Peter Psenak mailto:ppse...@cisco.com>>; Tony Przygienda mailto:tonysi...@gmail.com>> Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Hi Huaimo, > Introducing centralized feature into IGP will break IGP's distri

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

2018-08-28 Thread tony . li
> Can we focus on finding one common algorithms that can deducing the optimized > flooding topology based on the initial synchronized LSDB for further LSA > flooding reduction? We welcome proposals for algorithms that fulfill the requirements that have been discussed. So far …. crickets.

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

2018-08-28 Thread Christian Hopps
tony...@tony.li writes: 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

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

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 >

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

2018-08-27 Thread Robert Raszuk
tsura < > 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

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

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

2018-08-27 Thread Huaimo Chen
1: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 c

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

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

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

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

2018-08-27 Thread Huaimo Chen
ubject: 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. H

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

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

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

2018-08-24 Thread Tony Przygienda
On Fri, Aug 24, 2018 at 1:36 PM wrote: > > Tony, > > as to miscabling: yepp, the protocol has either to prevent adjacencies > coming up or one has to deal with generic topologies. If you don't want to > design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT > did) you have to

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

2018-08-24 Thread tony . li
Tony, > as to miscabling: yepp, the protocol has either to prevent adjacencies coming > up or one has to deal with generic topologies. If you don't want to design > miscabling prevention/topology ZTP into protocol (like ROLL or RIFT did) you > have to deal with generic graph as you say. I

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

2018-08-24 Thread tony . li
> 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. > For computing routes, we have been using distributed SPF on every node for > many years. True, but that algorithm is (and

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

2018-08-24 Thread John E Drake
12:17 PM > To: Peter Psenak ; tony...@tony.li > Cc: lsr@ietf.org; Jeff Tantsura ; Acee Lindem > (acee) > Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward > > Building on what Tony L and Peter have already stated: > > R1: Significant reduction in flo

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

2018-08-24 Thread Robert Raszuk
Tonys / Everyone, > moreover, I observe that IME ISIS is much more robust under such optimizations since the CSNPs catch (@ a somehow ugly delay cost) > any corner cases whereas OSPF after IDBE will happily stay out of sync forever if flooding skips something (that may actually become a > reason

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

2018-08-24 Thread Huaimo Chen
. Best Regards, Huaimo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Friday, August 24, 2018 12:29 PM To: Tony Przygienda Cc: lsr@ietf.org; Jeff Tantsura ; Peter Psenak ; Acee Lindem (acee) Subject: Re: [Lsr] LSR Flooding Reduction Drafts

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

2018-08-24 Thread Tony Przygienda
Hey Tony, as to miscabling: yepp, the protocol has either to prevent adjacencies coming up or one has to deal with generic topologies. If you don't want to design miscabling prevention/topology ZTP into protocol (like ROLL or RIFT did) you have to deal with generic graph as you say. I think that

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

2018-08-24 Thread tony . li
> a) we are talking any kind of topology for the solution, i.e. generic graph? Well, the problem with a topology restriction is that mistakes happen. If we have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and someone mistakenly inserts a leaf to leaf link, what

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

2018-08-24 Thread Peter Psenak
Hi Tony, On 24/08/18 17:03 , tony...@tony.li wrote: So, going Old Skool here: Since everyone agrees that this is a reasonable direction, how about we have a real discussion on the list? Requirement number 1 is straightforward: a significant reduction in flooding overhead. The basis for

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

2018-08-24 Thread Tony Przygienda
OK, good, real work. So from some scar tissue here's one question a) we are talking any kind of topology for the solution, i.e. generic graph? and then suggestion for IME realistic, operational MUST requirements b) req a): the solution should support distributed and centralized algorithm to

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

2018-08-24 Thread Acee Lindem (acee)
Speaking as WG member: I agree on this and don't believe we need a separate document or a protracted discussion. Additionally, I don't think we should worry about anything going on in other WGs. Thanks, Acee P.S. I'll provide more input to the discussion as well. As luck would have it, I

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

2018-08-24 Thread tony . li
So, going Old Skool here: Since everyone agrees that this is a reasonable direction, how about we have a real discussion on the list? Requirement number 1 is straightforward: a significant reduction in flooding overhead. The basis for this requirement is the understanding that in a dense

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

2018-08-24 Thread Peter Psenak
Hi Jeff, On 24/08/18 00:59 , Jeff Tantsura wrote: Peter, As previously stated - I'm against gating, it should be developed in parallel and with cooperation with the ongoing/existing work. Note - there's a document (albeit expired, it played its role) that talks about generic DC Routing

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

2018-08-23 Thread Jeff Tantsura
Peter, As previously stated - I'm against gating, it should be developed in parallel and with cooperation with the ongoing/existing work. Note - there's a document (albeit expired, it played its role) that talks about generic DC Routing requirements, work in LSR would be scooped to LSR only. So

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

2018-08-23 Thread Huaimo Chen
=40cisco@dmarc.ietf.org Cc: lsr@ietf.org; Jeff Tantsura ; Tony Li ; acee=40cisco@dmarc.ietf.org Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward I do think it is a good idea in a sense to somehow outline WHAT problem is being solved via some write-down or mind-melt a) I hope

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

2018-08-23 Thread Tony Przygienda
On Thu, Aug 23, 2018 at 2:05 AM Peter Psenak wrote: > ... > And to be > completely honest, the requirements are pretty straightforward for > anyone that is familiar with the protocols' operation. > > The signalling is quite simple as often the case, good quality algorithms, especially

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

2018-08-23 Thread Peter Psenak
Jeff, All, we have added many extensions to IGP protocols over the years. Many times multiple solutions were proposed for the same or similar problem and WG picked from the set, many times multiple solutions were merged or combined together. We never asked for a requirement document. Even for

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

2018-08-22 Thread Dean cheng
2 PM To: Dean cheng Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org; Jeff Tantsura ; Tony Li ; Acee Lindem (acee) Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Agreed. Also for the relatively-long term solution, I doubt there is an one-size-fits-all solution. We need to have en

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

2018-08-22 Thread Naiming Shen (naiming)
ant.i...@gmail.com>>; Tony Li mailto:tony1ath...@gmail.com>>; Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org>> Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward I do think to solve all the data centers (massive or small) requirement, this discussio

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

2018-08-22 Thread Dean cheng
y1ath...@gmail.com>>; Acee Lindem (acee) mailto:acee=40cisco@dmarc.ietf.org>> Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward I do think to solve all the data centers (massive or small) requirement, this discussion is very useful. If we can list all the requi

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

2018-08-22 Thread Les Ginsberg (ginsberg)
Works for me. Thanx Jeff. Les From: Jeff Tantsura Sent: Wednesday, August 22, 2018 1:21 PM To: Les Ginsberg (ginsberg) ; Tony Przygienda Cc: Tony Li ; lsr@ietf.org; Acee Lindem (acee) Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward Les, Not going to repeat Tony P

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

2018-08-22 Thread Jeff Tantsura
9 To: "Les Ginsberg (ginsberg)" Cc: Jeff Tantsura , Tony Li , "lsr@ietf.org" , "Acee Lindem (acee)" Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward I do think to solve all the data centers (massive or small) requirement, this discu

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

2018-08-22 Thread Jeff Tantsura
real benefits now – especially since we can do so in a way that is future-proofed. Les From: Tony Przygienda Sent: Wednesday, August 22, 2018 11:59 AM To: Les Ginsberg (ginsberg) Cc: Jeff Tantsura ; Tony Li ; lsr@ietf.org; Acee Lindem (acee) Subject: Re: [Lsr] LSR Flooding Red

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

2018-08-22 Thread Huaimo Chen
Shen (naiming) Sent: Wednesday, August 22, 2018 3:19 PM To: Les Ginsberg (ginsberg) Cc: lsr@ietf.org; Jeff Tantsura ; Tony Li ; Acee Lindem (acee) Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward I do think to solve all the data centers (massive or small) requirement

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

2018-08-22 Thread Tony Przygienda
usiness as usual” as regards > these drafts. > > > > > >Les > > > > > > *From:* Lsr *On Behalf Of *Jeff Tantsura > *Sent:* Wednesday, August 22, 2018 9:43 AM > *To:* Tony Li > *Cc:* lsr@ietf.org; Acee Lindem (acee) > *Subject:* Re: [Lsr] LSR Flooding Re

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

2018-08-22 Thread Les Ginsberg (ginsberg)
explain why we cannot proceed with “business as usual” as regards these drafts. Les From: Lsr On Behalf Of Jeff Tantsura Sent: Wednesday, August 22, 2018 9:43 AM To: Tony Li Cc: lsr@ietf.org; Acee Lindem (acee) Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward +1 Tony We

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

2018-08-22 Thread Jeff Tantsura
+1 Tony We could start with a document, similar to dc-routing requirements one we did in RTGWG before chartering RIFT and LSVR. Would help to disambiguate requirements from claims and have apple to apple comparison. Doing it on github was a good experience. Regards, Jeff > On Aug 22, 2018,

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

2018-08-22 Thread Tony Li
> At IETF 102, there was no dearth of flooding reduction proposals. In fact, > we have so many proposals that there wasn’t agree as how to move forward and > we agreed to discuss on the list. This Email is to initiate that discussion > (which I intend to participate in but as a WG member).