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

Christian Hopps <chopps@chopps.org> Tue, 11 September 2018 00:39 UTC

Return-Path: <chopps@chopps.org>
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 5313C12F18C for <lsr@ietfa.amsl.com>; Mon, 10 Sep 2018 17:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 fXKp0qHE7nyi for <lsr@ietfa.amsl.com>; Mon, 10 Sep 2018 17:39:17 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 81E3D1271FF for <lsr@ietf.org>; Mon, 10 Sep 2018 17:39:17 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2C927611B3; Tue, 11 Sep 2018 00:39:16 +0000 (UTC)
References: <8F5D2891-2DD1-4E51-9617-C30FF716E9FB@cisco.com> <C64E476F-1C00-435E-9C74-BEC3053377E8@gmail.com> <2F5FDB3F-ADCA-4DB4-83DA-D2BC3129D2F2@gmail.com> <5B7E78DD.90302@cisco.com> <172728E8-49E6-4F43-9356-815E1F4C22E7@gmail.com> <5B7FCAB3.6040600@cisco.com> <3D1DEC37-ACE7-4412-BB2E-4C441A4E7455@tony.li> <CCF220A3-8308-47B8-8CC6-1989705FF05C@cisco.com> <CA+wi2hNv8AVyR81LRmJ=Pd5_p5rS2djCOjY9YDgKxG=KEO_MkA@mail.gmail.com> <39509D13-4D2D-49A9-8738-C9D1F7C54223@tony.li> <5316A0AB3C851246A7CA5758973207D463ABCF95@sjceml521-mbx.china.huawei.com> <54F4EE88-981B-4EB1-925B-B3573B28DAD3@tony.li> <5316A0AB3C851246A7CA5758973207D463AC1E20@sjceml521-mbs.china.huawei.com> <CAOj+MMEELgcwwQQ6bqUb4DZEUX_3eM3ADw-c6N-4FBaf6Pkp=Q@mail.gmail.com> <5316A0AB3C851246A7CA5758973207D463AC1EEC@sjceml521-mbs.china.huawei.com> <CAOj+MMFDWJ39pP1h1m1savT1DP5vt0HSrO=-=-1TMMPBL8WsKg@mail.gmail.com> <5316A0AB3C851246A7CA5758973207D463AC49E9@sjceml521-mbs.china.huawei.com> <BN7PR05MB4354C05F1E11B8A548F991C4C7080@BN7PR05MB4354.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D463AC5ECB@sjceml521-mbs.china.huawei.com> <BN7PR05MB4354AA047A9886D8A5227FCCC7030@BN7PR05MB4354.namprd05.prod.outlook.com> <5316A0AB3C851246A7CA5758973207D463AC5F49@sjceml521-mbs.china.huawei.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps <chopps@chopps.org>
To: Huaimo Chen <huaimo.chen@huawei.com>
Cc: John E Drake <jdrake@juniper.net>, Robert Raszuk <robert@raszuk.net>, "tony.li@tony.li" <tony.li@tony.li>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, Tony Przygienda <tonysietf@gmail.com>, Peter Psenak <ppsenak@cisco.com>
In-reply-to: <5316A0AB3C851246A7CA5758973207D463AC5F49@sjceml521-mbs.china.huawei.com>
Date: Mon, 10 Sep 2018 20:39:15 -0400
Message-ID: <sa6efe0c1fw.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/y5dBQ4t1ZcW95tPULZo5hbzdXso>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
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: Tue, 11 Sep 2018 00:39:22 -0000

> [JD]  Both discuss centralized and distributed
> [HC] Both drafts talk about both now. It is not reasonable to say one is a derivative of another.

I think calling the OSPF draft a derivative of the other was probably counter-productive here, and if we consider the earlier publications, it is technically wrong. As originally presented each draft seemed to focus on one type of solution. It's important that people are given credit for work they have done and ideas they have had.

That said, it's also important to consider the quality of the work, and when the distributed OSPF solution was first presented there were some obvious problems with the algorithm that were raised in the room during the meeting by people after having just seen the work for the first time.

Now I'm assuming John arrived at his conclusion of one being a derivative of the other based on reading the drafts as they stand now. So while the conclusion may have been historically incorrect, it also may be indicative of which document is of higher quality and better suited for use by the WG going forward.

Thanks,
Chris.

Huaimo Chen <huaimo.chen@huawei.com> writes:

> Hi John,
>
>     See my comments inline below.
>
> Best Regards,
> Huaimo
> From: Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>>
> Sent: Tuesday, September 4, 2018 9:50 AM
> To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> Cc: tony.li@tony.li<mailto:tony.li@tony.li>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>; Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>>; Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>
> Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
> Hi John,
>
>> I have reviewed both of the flood reduction drafts and the draft referenced below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative document inferior in >quality to the draft, draft-li-dynamic-flooding-05, from which it is derived.  For example, the referenced draft fails to include a description of the message used to deliver the >flooding topology when using centralized mode, it neglects to include any analysis of error conditions, and it neglects to include any description of the interactions with down->level nodes.
> It seems that your word “derivative” is not correct. Our draft originally focuses on distributed solution, Tony’s on centralized one. It is not reasonable to say that a distributed solution is a derivative from a centralized one.
>
> [JD]  Both discuss centralized and distributed
> [HC] Both drafts talk about both now. It is not reasonable to say one is a derivative of another.
>
> Regarding to missing message for centralized mode in our draft as you mentioned, it is for new ones to be added. We will fill this gap.
>
> [JD] Please see:   https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-5
>
> Regarding to missing analysis of error conditions, we will consider and add it.
>
> [JD] Please see:   https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.6
> [HC] For this, our draft talks about it. We will add more in details.
>
> Regarding to interactions with down-level nodes, can you give more details?
>
> [JD]  Please see:   https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4, https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.1
> [HC] For this, our draft talks about it.
>>Yours Irrespectively,
>>
>>John
>
> From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Huaimo Chen
> Sent: Thursday, August 30, 2018 11:01 AM
> To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> Cc: tony.li@tony.li<mailto:tony.li@tony.li>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>; Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>>; Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>
> Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward
>
> Hi Robert,
>
>>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed mode, centralized one or static one smoothly.
>>Aside from static approach can you summarize in purely technical points advantages your draft proposes over draft-li-dynamic-flooding-05 ?
> Initially, our draft focused on distributed solution for flooding reduction, and Tony’s on centralized way. This should be one advantage. Distributed solution is more practical.
> In addition, we proposed the followings during the progress of our draft:
>
> 1)    A method to allow flooding topology to be lean and to allow multiple failures in an area;
>
> 2)    A procedure for establishing a new adjacency between a (new) node and  an existing node supporting flooding reduction;
>
> 3)    A way in which one touch (or command) to enable flooding reduction in a whole area within a short time;
>
> 4)    A way in which one touch (or command) to rollback flooding reduction to normal flooding in a whole area smoothly;
>
> 5)    A TLV for distributing the priority of a node to become a leader;
>
> 6)    Three algorithms for building a flooding topology.
> Distributed solution for flooding reduction is stable after we resolve the issues raised by other experts during the last few IETFs.
> BTW, as a service provider, which mode/solution (distributed or centralized) will you select to use in an operational network?
>
> Best Regards,
> Huaimo
>>Many thx,
>>R.
>
>
>
> On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>> 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 networks today :)
>
> 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.
>
>>Btw I don't think there is any problem here ... The text added to -05 version allows very seamless choice of centralized vs distributed topology computation by signalling either zero or non zero value in the added to version -05 area leader sub-tlv.
>>
>>In other words I don't see any problem or room for debate .. adopting and implementing -05 allows use of centralized or distributed optimal flooding computation at the operator's discretion.
>
> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed mode, centralized one or static one smoothly.
>
> Best Regards,
> Huaimo
>
> From: Robert Raszuk [mailto:robert@raszuk.net<mailto:robert@raszuk.net>]
> Sent: Monday, August 27, 2018 11:31 AM
> To: Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>>
> Cc: tony.li@tony.li<mailto:tony.li@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>; Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>; Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>>
> Subject: 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 information - typically 1RU linux blade -  here optimized flooding graph. But this never was the plan with this proposal from its start ie. -00 version.
>
> Centralized means that optimized flooding graph comes from single redundant node.
>
> 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 networks today :)
>
> To your point of multi-vendor networks true - and that is precisely why upgrade network wide to a release containing consistent algorithm from more then a single vendor (and even for single vendor) is practically a very time consuming and difficult process.
>
> Btw I don't think there is any problem here ... The text added to -05 version allows very seamless choice of centralized vs distributed topology computation by signalling either zero or non zero value in the added to version -05 area leader sub-tlv.
>
> In other words I don't see any problem or room for debate .. adopting and implementing -05 allows use of centralized or distributed optimal flooding computation at the operator's discretion.
>
> Thx,
> R.
>
> On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>> wrote:
>>> 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 distributed in nature. Introducing centralized feature into IGP will break IGP's distributed nature, which may cause some issues/problems.
>
>>> For computing routes, we have been using distributed SPF on every node for many years.
>>True, but that algorithm is (and was) very well known and a fixed algorithm that would clearly solve the problem at the time. If we were in a similar situation, where we were ready to set an algorithm in >concrete, I might well agree, but it’s quite clear that we are NOT at that point yet.  We will need to experiment and modify algorithms, and as discussed, that’s easier with a centralized approach.
> After flooding reduction is deployed in an operational (ISP) network, will we be allowed to do experiments on their network?
> After an algorithm is determined/selected, will it be changed to another algorithm in a short time?
>
>>> In fact, we may not need to run the exact algorithm on every node. As long as the algorithms running on different nodes generate the same result, that would work.
>>Insuring a globally consistent result without running the exact same algorithm on the exact same data will be quite a trick.  Debugging distributed problems at scale is already a hard problem.  Having >different algorithms in different locations would add another order of magnitude in difficulty.  No thank you.
> In some existing networks, some nodes run IGPs from one vendor, some other nodes run IGPs from another vendor, and so on. Some may use normal SPF, some others may use incremental SPF. It seems that we have had these cases for many years.
>>Tony
>
> Best Regards,
> Huaimo
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org<mailto:Lsr@ietf.org>
> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=dQNetSHGAsFGcKk3dMxdWF6zY3NJc1cUOiTIkr-KOMA&s=aj_vuMJsmKUm-qly2FE2m_7WtK2ra7w4ftfPz37zXB8&e=>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr