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

"Naiming Shen (naiming)" <naiming@cisco.com> Thu, 23 August 2018 00:42 UTC

Return-Path: <naiming@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 7C828130E55 for <lsr@ietfa.amsl.com>; Wed, 22 Aug 2018 17:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, 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 NKhX3tv43soG for <lsr@ietfa.amsl.com>; Wed, 22 Aug 2018 17:42:02 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8739812F18C for <lsr@ietf.org>; Wed, 22 Aug 2018 17:42:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48682; q=dns/txt; s=iport; t=1534984922; x=1536194522; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/Z6N2gDk71K+b/Zka7V29U3sYHPcEnvbjk7X8yMM3Ks=; b=iSinu2BiTTcBpwIns7rbW9rMr01O6u5UI/LrUMejGmkJFCvsmSiNslxz au9jWVtKkQ9cZtW8UWsvOTA2CPtWU/+BhymO2VIBM7QCUzHsvDdwOLXXM 8/330rQZj4LxTSjIU1UZrruqzTniO6ZsYhDrVKRstgCluAMRRS8dHobJb A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CxAACGAX5b/5hdJa1aGQEBAQEBAQEBAQEBAQcBAQEBAYJXeGV/KAqDZYgNjCaCDYhTjUsUgWMDCxgBCoRJAheCbyE0GAECAQECAQECbRwMhTcBAQEEAQEhSwsQAgEIEQQBASEBBgMCAgIfBgsUCQgCBA4FG4MHAYEdTAMVD6NBgS6HIQ2DLAWJHReCAIESJx+CHi6CVkUBAQKBLAESATYfgksxgiYCjQGNURcrCQKGLIYqgxAXgT6EL4hPixVihx4CERSBJB04YXFwFTsqAYIKATOBdTAXiFmFPm8BjCKBH4EcAQE
X-IronPort-AV: E=Sophos;i="5.53,276,1531785600"; d="scan'208,217";a="161214471"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2018 00:42:01 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w7N0g1c6017185 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Aug 2018 00:42:01 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Aug 2018 19:42:00 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Wed, 22 Aug 2018 19:42:00 -0500
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: Dean cheng <dean.cheng@huawei.com>
CC: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, Tony Li <tony1athome@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
Thread-Index: AQHUOZzx1fG+ry0N80OZf0oWOKvmqqTMSsQAgAAEEQD//7bXcIAAdOEAgABUsgCAAAWLgA==
Date: Thu, 23 Aug 2018 00:42:00 +0000
Message-ID: <1068E04F-1F34-4E83-9FCB-07045AC5FE07@cisco.com>
References: <8F5D2891-2DD1-4E51-9617-C30FF716E9FB@cisco.com> <C64E476F-1C00-435E-9C74-BEC3053377E8@gmail.com> <2F5FDB3F-ADCA-4DB4-83DA-D2BC3129D2F2@gmail.com> <5579bc6a6fd9443f87d148312c004d7f@XCH-ALN-001.cisco.com> <084EFAA2-D0BE-4197-8394-C7597A30C3F9@cisco.com> <DC7880973D477648AC15A3BA66253F68822E3B16@sjceml521-mbx.china.huawei.com>
In-Reply-To: <DC7880973D477648AC15A3BA66253F68822E3B16@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.156.165.56]
Content-Type: multipart/alternative; boundary="_000_1068E04F1F344E839FCB07045AC5FE07ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7b2cO4mW-rzTRe-G-i3LlL9y_-A>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 23 Aug 2018 00:42:06 -0000

Agreed. Also for the relatively-long term solution, I doubt there is
an one-size-fits-all solution. We need to have enough building blocks
in protocols and any data center design/operation can utilize with
to achieve their operational goal.

Regards,
- Naiming

On Aug 22, 2018, at 5:22 PM, Dean cheng <dean.cheng@huawei.com<mailto:dean.cheng@huawei.com>> wrote:

This two-approach approach makes sense, since it tends to provide a solution
in a short term but also lay out a foundation for the relatively-long term. And
hopefully some elements deployed in the short term can be leveraged and
further tuned for the long term solution.

Dean

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Naiming Shen (naiming)
Sent: Wednesday, August 22, 2018 12:19 PM
To: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>; Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@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 requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>> wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable interest was expressed in working on enhancements to existing Link State protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move forward on two new protocols (no objection from me) but seems to feel there is insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these drafts.


   Les


From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Jeff Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>
Subject: 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, at 09:27, Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>> wrote:




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


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about requirements.  There seem to many different perceptions.

Regards,
Tony


_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www..ietf.org/mailman/listinfo/lsr<https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr