Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

Peter Psenak <ppsenak@cisco.com> Wed, 29 May 2019 07:25 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A86120121 for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 00:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5y4e1qnJZkV for <lsr@ietfa.amsl.com>; Wed, 29 May 2019 00:25:48 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDBE120052 for <lsr@ietf.org>; Wed, 29 May 2019 00:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3446; q=dns/txt; s=iport; t=1559114747; x=1560324347; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=x/5AfRVNwOMuShQpOdSZJlEQ2vqVoehIpLZI83vi/yI=; b=ROJMAFt6drMUpW9vjrtdnTkPBfVn7g6s5WV4WeHBHhhO8JV2vn47irag FF2rBFg/976Donb+qEScyS4I7gx2zIcaZsqPv+Xc2iftVS3MvxEw4KKwF 8jjskyJdcxc8ZUz5Pt4udaW0zsrTFGHt0mb5APxTmZW+FgXqNw3yvXHVM 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAABAM+5c/xbLJq1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUgMBAQEBAQsBgWaBE1EBIBIohBOIe4wBJYlCjxkUgWcJAQEBDhgLDAEBhEACgxA1CA4BAwEBBAEBAgEEbRwMhUoBAQEBAgEBASEPAQU2CwULCQIYAgIjAwICIQYfBgsGAQwGAgEBglNLAYFqAw4PD40im2qBL4VHgkMNXYFABoEMKAGLaYFAP4E4DIFhUC4+ghpHAQGBOg+DIoJYBIsnh32HWhiNCT0Jgg+CE40mgTSCKgYbjGGCFIdajHSIXo1FgVEBNYFXMxoIGxU7gmyCRhqIM4VBPQMwjFWCUgEB
X-IronPort-AV: E=Sophos;i="5.60,526,1549929600"; d="scan'208";a="12517963"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 May 2019 07:25:45 +0000
Received: from [10.60.140.55] (ams-ppsenak-nitro6.cisco.com [10.60.140.55]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x4T7Piki012613; Wed, 29 May 2019 07:25:45 GMT
To: Aijun Wang <wangaijun@tsinghua.org.cn>, 'Tony Li' <tony1athome@gmail.com>, 'Robert Raszuk' <robert@raszuk.net>
Cc: lsr@ietf.org
References: <5316A0AB3C851246A7CA5758973207D463BBD21B@sjceml521-mbs.china.huawei.com> <BYAPR11MB3638190EC8AD3235AB2304E7C1060@BYAPR11MB3638.namprd11.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D463BC5C32@sjceml521-mbx.china.huawei.com> <BYAPR11MB3638722A90E40777657001B8C1000@BYAPR11MB3638.namprd11.prod.outlook.com> <CAOj+MMEijyB7qd4oUaOe7W19j+76CjH+mzJ3mvcVtOjn5fvmdw@mail.gmail.com> <BYAPR11MB363863B393A181264E07B042C1000@BYAPR11MB3638.namprd11.prod.outlook.com> <MN2PR13MB3470B24A328311A23BAAC5B8A3000@MN2PR13MB3470.namprd13.prod.outlook.com> <MN2PR13MB34701B410A172A950BAE6B5EA31C0@MN2PR13MB3470.namprd13.prod.outlook.com> <FB4EDF4B-C94D-4654-8D3A-A1567E0D76B1@gmail.com> <CAOj+MMGDodnxktZCuqPfVDCRbu0+yUR--DiZKTqVQ=4thAM5rw@mail.gmail.com> <4DFD8BB4-AA63-4BE6-9927-4557AB32ABD9@gmail.com> <005401d5151c$cbda8120$638f8360$@org.cn> <e2b23e19-4a0a-3ad6-e647-c1afde1e5e 56@cisco.com> <003601d515bf$f2870750$d79515f0$@org.cn>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <338c3a6e-3d85-1592-32a2-0dc47388f46e@cisco.com>
Date: Wed, 29 May 2019 09:25:43 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <003601d515bf$f2870750$d79515f0$@org.cn>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.55, ams-ppsenak-nitro6.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0C_i56fwl7M9tLTQ9k-Wr523t7s>
Subject: Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 07:25:50 -0000

Hi Aijun,

On 29/05/2019 03:43, Aijun Wang wrote:
> Hi, Peter:
> 
> Under the current mechanism, only all the candidate area leaders stop advertise this sub-TLV, then the network will be back to normal flooding?

no.

> Is it more efficient that only one area leader indicates(according to the command from NMS) explicitly then the network will be back to normal flooding?

yes and we have that in the draft:

"When the Area Leader advertises algorithm 0 in its Area Leader Sub-
    TLV and does not advertise a flooding topology, Dynamic Flooding is
    disabled for the area.  Note this applies whether the Area Leader
    intends to operate in centralized mode or in distributed mode."
> 
> For the number of candidate area leaders, I support we should have more than one for consideration of redundancy.

sure.

thanks,
Peter
> 
> -----邮件原件-----
> 发件人: Peter Psenak [mailto:ppsenak@cisco.com]
> 发送时间: 2019年5月28日 15:34
> 收件人: Aijun Wang; 'Tony Li'; 'Robert Raszuk'
> 抄送: lsr@ietf.org
> 主题: Re: [Lsr] 答复: Option B from "Migration between normal flooding and flooding reduction"
> 
> Aijun,
> 
> On 28/05/2019 08:15, Aijun Wang wrote:
>> Hi, Tony:
>>
>> How the receiver judge the leader has stopped advertising the Area Leader sub-TLV? Do you need some timers?
> 
> no timer needed, all event driven. Area Leader sub-TLV is removed from the LSP.
> 
> thanks,
> Peter
> 
>> >From the current discussion, I think the explicit instruction that proposed by Huaimo is more acceptable.
>>
>>
>> Best Regards.
>>
>> Aijun Wang
>> Network R&D and Operation Support Department China Telecom Corporation
>> Limited Beijing Research Institute,Beijing, China.
>>
>> -----邮件原件-----
>> 发件人: Tony Li [mailto:tony1athome@gmail.com]
>> 发送时间: 2019年5月27日 12:20
>> 收件人: Robert Raszuk
>> 抄送: lsr@ietf.org
>> 主题: Re: [Lsr] Option B from "Migration between normal flooding and flooding reduction"
>>
>>
>> Hi Robert,
>>
>>> The current draft is pretty robust in terms of area leader election. It also says that  "Any node that is capable MAY advertise its eligibility to become Area Leader”
>>
>>
>> Correct.  This can be all systems. It can be one. For redundancy, a few would be sensible.
>>
>>
>>> With that can you confirm the procedure to "resign" as area leader ?
>>
>>
>> Stop advertising the Area Leader sub-TLV.  It’s that simple.
>>
>>
>>> Especially that under those circumstances just having active area leader to resign clearly is not enough to change given flooding scheme.
>>
>>
>> If there are multiple potential area leaders, then all of them would have to resign.
>>
>>
>>> In some deployments all eligible nodes may advertise such capability which in turn the "resign" procedure would require NMS action to disable such capability by configuration and re-flooding it. Not that I am advocating it nor see need for complex migration procedures, but just would like to better understand the "resign" part.
>>
>>
>> Correct, this is rightfully an NMS operation.
>>
>> 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
>>
>>
> 
> 
>