Re: [Lsr] Flooding Negotiation bit

2019-05-21 Thread Les Ginsberg (ginsberg)
;mailto:tony...@tony.li> Cc: lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] Flooding Negotiation bit Hi Tony, There are two different cases in which a link is to be added to the FT temporarily. In one case, a negotiation is needed to be done before a link is to be added to the F

Re: [Lsr] Flooding Negotiation bit

2019-05-20 Thread Huaimo Chen
Subject: Re: [Lsr] Flooding Negotiation bit Hi Tony, There are two different cases in which a link is to be added to the FT temporarily. In one case, a negotiation is needed to be done before a link is to be added to the FT temporarily. In the other case, no negotiation is needed. It is determi

Re: [Lsr] Flooding Negotiation bit

2019-05-17 Thread Les Ginsberg (ginsberg)
address the issue. I don’t think what you propose is needed – and if it were needed I do not think it would belong in flooding optimizations draft. Les From: Lsr On Behalf Of Huaimo Chen Sent: Wednesday, May 15, 2019 8:07 AM To: tony...@tony.li Cc: lsr@ietf.org Subject: Re: [Lsr] Flooding

Re: [Lsr] Flooding Negotiation bit

2019-05-17 Thread Acee Lindem (acee)
Hi Gyan, From: Gyan Mishra Date: Friday, May 17, 2019 at 3:31 AM To: Acee Lindem Cc: Huaimo Chen , "lsr@ietf.org" , Tony Li Subject: Re: [Lsr] Flooding Negotiation bit Les We do have cases with adjacencies around around the 100 range and the process overhead is much worse for

Re: [Lsr] Flooding Negotiation bit

2019-05-17 Thread Gyan Mishra
ty to your existing deployed networks. > > Thanks, > Acee > > > > *From: *Lsr on behalf of Gyan Mishra < > hayabusa...@gmail.com> > *Date: *Tuesday, May 14, 2019 at 9:57 PM > *To: *Tony Li > *Cc: *Huaimo Chen , "lsr@ietf.org" > *Subject: *Re: [L

Re: [Lsr] Flooding Negotiation bit

2019-05-15 Thread Huaimo Chen
Hi Tony, There are two different cases in which a link is to be added to the FT temporarily. In one case, a negotiation is needed to be done before a link is to be added to the FT temporarily. In the other case, no negotiation is needed. It is determined that a link is added to the FT temporari

Re: [Lsr] Flooding Negotiation bit

2019-05-15 Thread Acee Lindem (acee)
Cc: Huaimo Chen , "lsr@ietf.org" Subject: Re: [Lsr] Flooding Negotiation bit Is this a new option that does not exist today in OSPFv3 or ISIS. Operators have the ability to mark interfaces as passive so only router stub LSA is generated which helps assist in full SPF calculation

Re: [Lsr] Flooding Negotiation bit

2019-05-14 Thread Gyan Mishra
Is this a new option that does not exist today in OSPFv3 or ISIS. Operators have the ability to mark interfaces as passive so only router stub LSA is generated which helps assist in full SPF calculations flooding. Gyan S. Mishra IT Network Engineering & Technology Verizon Communications Inc. (

Re: [Lsr] Flooding Negotiation bit

2019-05-14 Thread tony . li
Hi Huaimo, If I understand you correctly, this seems to have almost the same semantics as the Flooding Request TLV (section 5.1.5) or the Flooding Request Bit (section 5.2.7). If I’m not understanding you, could you please clarify the differences and why the current mechanisms are insufficien

[Lsr] Flooding Negotiation bit

2019-05-14 Thread Huaimo Chen
Hi Tony, For the case you described below, in order to add one or a limited number of links to the flooding topology temporarily, a new bit, called Flooding Negotiation bit (FN bit for short), should be defined and used. In OSPF, the FN bit is defined in Extended Options and Flag (EOF) TLV in O