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

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

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

: 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

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

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

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

> 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

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

> 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

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

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

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

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

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

. 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

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

> 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

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

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

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

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

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

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

=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

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

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

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

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

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

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

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

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

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

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

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

+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

> 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).