Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Gyan Mishra <hayabusagsm@gmail.com> Fri, 29 May 2020 03:14 UTC

Return-Path: <hayabusagsm@gmail.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 EE8413A08C5 for <lsr@ietfa.amsl.com>; Thu, 28 May 2020 20:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aRTblvnwNgsY for <lsr@ietfa.amsl.com>; Thu, 28 May 2020 20:14:56 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB693A08C1 for <lsr@ietf.org>; Thu, 28 May 2020 20:14:56 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id d5so804018ios.9 for <lsr@ietf.org>; Thu, 28 May 2020 20:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FWK9Y16MRfZSK29KkADfCHVjlj4/Ef68XKSOBL2Qn/0=; b=hrK7wm1JE4dzvCr0fWKn3Y8Q9azR8b8DL2/MsC8Rkth7dfbNw5YxDtLCplsv7q6bLy 43Cd1l+96L1BfB/53lMZLdjyiAB3MyZfgwb7V1e3lyru4/FUjMhlJe0rbGPEjp3wuJZb AWB6rZJbDP7pDWndTZTEXCtHERXaIP6Webuo2Ey7ZS7JmC6u4Ae0RC+bqj9sPJ+mkZdL mxg3IMPshliOekZcSoRihpdgO3h2+sllqAM4h06Ezc1GJODljKAGfTYNk29p5mJal2a7 Kl2mGZmJ4TgW74L6iLRs/va2wp2fux63fDoUioaAx2f/oun4XegRfnZOzK0uSurEUFh4 /6mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FWK9Y16MRfZSK29KkADfCHVjlj4/Ef68XKSOBL2Qn/0=; b=OJXHbLYqANFNdhiuEfodGfnlJ6HXwMUC2X806Zg+qT5mpa2E0zdRCrnbsV1Cxhuxy+ 8L7KmOxP/ISikCV8OP0luQpxLlUJB5AbmmkW57VyN0nVZtsFic8ASXGwVT+2s/sG8mpz BEyK+cWl9QsWjOSFqx1uCtv0WejOXsxW00CkFDYC6rxtOMBSkzNkzcU9hVPcQegjzhKq C3LdQi75wQ2YOKgVV1d7B96TEVDXzbretIi2Pp8cB5VmFqGRHh1kG9VLcJRZpOsC5tbf pRHYp+aMh9gogbv+VLHtlfW566o03ng5X2ZtMdqBGGyE3IjPHRBbn01PsYEPFmFp9H9/ gN/w==
X-Gm-Message-State: AOAM531Pc75uy9CeRqnrR6wenM193kC8y6PODW0ZHsO29QoZVff4TykZ owoeO3D95RSMXWUWTshpUnGyP6R3+GkG42R28u0=
X-Google-Smtp-Source: ABdhPJxXXjbQZgoGkNryMjTmQhmbBuGHYZpmbbm3SxSYnbM/WV+Uv/jlQwnGZIERoF3pbqJonyeXy3jxfnjCcL1tgPY=
X-Received: by 2002:a02:1c83:: with SMTP id c125mr5486390jac.112.1590722095553; Thu, 28 May 2020 20:14:55 -0700 (PDT)
MIME-Version: 1.0
References: <63330FD6-EDE8-4938-AA85-948279C57E34@cisco.com> <DM6PR06MB509842BA0E42A4938ACB2B94EEB80@DM6PR06MB5098.namprd06.prod.outlook.com> <CABNhwV3jQ=C6ynJBsKhJW_b=hkq7CKPFG2ci0vXE_0jZH9KtXQ@mail.gmail.com> <MN2PR13MB3117C43CA052E4E29D7428CBF2B60@MN2PR13MB3117.namprd13.prod.outlook.com> <CABNhwV2Y3kemTdHYBamZwAB+m5DefxqTC0shPan2cGHd9TARTg@mail.gmail.com> <98470E08-B758-45F4-930D-60015D2EAA3B@tony.li> <SA0PR11MB462438CE12785AD7B2372BAFC1B10@SA0PR11MB4624.namprd11.prod.outlook.com>
In-Reply-To: <SA0PR11MB462438CE12785AD7B2372BAFC1B10@SA0PR11MB4624.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 28 May 2020 23:14:44 -0400
Message-ID: <CABNhwV2ioze9q9YDzijHB78q2Xp_bzOxxiZhoenuy6b5WO=6Tw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Huaimo Chen <huaimo.chen@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org>, "tony.li@tony.li" <tony.li@tony.li>
Content-Type: multipart/alternative; boundary="000000000000711fa905a6c0d9af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/nQzOf76kI8uSQDWBzKQtAOZ-OH8>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
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: Fri, 29 May 2020 03:14:59 -0000

Les & Tony

Please see my replies inline

On Wed, May 27, 2020 at 1:49 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> Tony/Gyan –
>
>
>
> Please find my replies inline.
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of * tony.li@tony.li
> *Sent:* Wednesday, May 20, 2020 8:48 AM
> *To:* Gyan Mishra <hayabusagsm@gmail.com>
> *Cc:* lsr@ietf.org; Huaimo Chen <huaimo.chen@futurewei.com>om>; Acee Lindem
> (acee) <acee=40cisco.com@dmarc.ietf.org>
> *Subject:* Re: [Lsr] Flooding Topology Computation Algorithm -
> draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
>
>
>
>
>
> Hi Gyan,
>
>
>
>
>
> This is a much needed feature that operators have been needing for densely
> meshed topologies that commonly exist in data centers to accommodate very
> high bandwidth E-W traffic.
>
>
>
> Thank you.
>
>
>
> Please look at the feature description and it does seem to be exactly the
> same as this draft.  Please confirm.
>
>
>
>
>
> It would appear to be a different, proprietary, and unpublished algorithm.
>
>
>
>
> *[Les:] Yes, this is a different algorithm than either
> https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/
> <https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/>
> or  https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/
> <https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/>*
>
* <https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/>*
>
> *We are contemplating submitting a draft for this algorithm to the WG.*
>
> * Gyan> I think that would  be good for your customers so it’s not
> proprietary.*
>
>
>
>
>
> This will give us three different implementations, using three different
> algorithms, none of which will inter-operate.  Whee!!! :-(
>
>
>
>
>
> *[Les:] As I understand it, draft-chen only supports centralized mode –
> which is why it is Informational track and does not have interoperability
> concerns.*
>
> *Sarah/Tony - do you have plans to extend this to support distributed mode
> and then standardize it?*
>
>
>
> *At present there are no standard algorithm candidates which have achieved
> WG status – though that likely will change very soon.*
>
> *And the point of allowing multiple standardized algorithms to be defined
> was in the expectation that more than one might be proven useful.*
>
> * Gyan> So along those same lines in theory we could have hypothetically 3
> algorithms and all three on standards track which would give operators like
> Verizon and 3 options to pick from based on the physical topology use case.*
>
*Caveat would be - would vendors really want to develop other vendors
> options at a cost especially if there are more then two or rather keep
> their own option proprietary.  I think *
>
There maybe other features that you could get away with interoperability
> not being a concern but I think the flooding algorithm I would think would
> have to be the same for 2 vendors to be interoperable.
>
> There maybe other vendors due to industry demand have to get the feature
> deployed before it reaches standards vendor consensus with the IETF.
>
>
>
>
>
> Our implementation shipped last year.
>
>
>
> *[Les:] As did Cisco’s.*
>
>
>
>
>
> We are testing this feature and planning to deploy but wanted to ensure
> that this is the same as the draft on the standards track.
>
>
>
>
>
> It does not appear to be, but someone from Cisco should confirm.
>
>
>
> *[Les:] Confirmed.*
>
>
>
> *   Les*
>
>
>
> Tony
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD