Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt

Gyan Mishra <hayabusagsm@gmail.com> Sat, 03 October 2020 00: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 E7C3F3A1761 for <lsr@ietfa.amsl.com>; Fri, 2 Oct 2020 17:14:14 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 EdUc3c69GSJW for <lsr@ietfa.amsl.com>; Fri, 2 Oct 2020 17:14:12 -0700 (PDT)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 A99863A175F for <lsr@ietf.org>; Fri, 2 Oct 2020 17:14:12 -0700 (PDT)
Received: by mail-ua1-x92d.google.com with SMTP id q26so834173uaa.12 for <lsr@ietf.org>; Fri, 02 Oct 2020 17:14:12 -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=AmLvy556Eh6uyO+EwleF1VdBIW90W6zND+w1hxLlfO4=; b=a4thdO884PZtjsiAQgc6IPHK1q50YXZTDnxVBYrUq0ppvzMjvarn+qP5nct4xbfebw +xqPeYKBbaknYEjB+jYxkfirNYUvWc9bULgu5r+q9+XWlo/mMHC0OZeUCcRi40Ho9LT+ vFOCIA7CWN5V1ccK+mt65szXGmDej+Mj50o6aibXoAVhnDiRn79ymofLVrto6IrwEpwj BBi1xqAmZPkJrXK60I+POU2rrD0wDTmEUYGD5bKfCYl7NPpBYE4hIsPSEfW4biY/WtQg H5iMktalmYN9XLvO+GbuvfcBxd0fvPXPK2URUZurNW8OsXIM8sa1Zp9+4EQOcaShCGW5 Atfg==
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=AmLvy556Eh6uyO+EwleF1VdBIW90W6zND+w1hxLlfO4=; b=klaJNnkJVv41ZIJY2FQcUOa1cFTOmNuzajqYwv2bpd5MZxsYlEn9rl7UW4YeKOAHfd nOM40Z00hcnUG7SDH3dw04J8RQCwCUvuJYJRX5H4U6OSVjZ/zAKRCYCgYLzn0Sf4b8eW Tpy7QvvH1lYDpo3Lib7nIuPjq0sU3xiVmNcJWFWRRXHRR2VsGD66iR+Avij7iIrngQvx 4DM7Qr++bdDD1MP8VByxmfQas1zcokbS/NfpS3J7W8HgxpYmQ6gwO45PGJ+9AnWCINcQ Dj2k+GcJkA0cWyZ1wZHK5Ohd6JByRUYq7WW/9kpFmRcK7ks6CN0lkSE7B4olwV0cKe7L IuwQ==
X-Gm-Message-State: AOAM531sBAFmHyarMp/HcKz3tD2oWa9ynmC6geBqDnTfKxNg4DXNuNe8 hXCN23Q9FIxL83B+sgdoMakdwUbnjBc67YKIKwFCle1q5OxUWA==
X-Google-Smtp-Source: ABdhPJyDZhfeZr/d2gVnLxrx989N9WOpTaKBb1pYMvce4q1NcuoUYpo/idzHArDWTMRF7io0EQSKfAQ6FwYa5JWBv70=
X-Received: by 2002:a9f:301e:: with SMTP id h30mr2335339uab.114.1601684051608; Fri, 02 Oct 2020 17:14:11 -0700 (PDT)
MIME-Version: 1.0
References: <160138654056.12980.329207214151594381@ietfa.amsl.com> <DM6PR05MB63482DBC001DD56BEF6F7311AE320@DM6PR05MB6348.namprd05.prod.outlook.com> <CAKz0y8w5VOf_=baG6UCP8Q9s=VLM2ghT2jhiF5FZNN4JXB23eA@mail.gmail.com> <DM6PR05MB63485389C261CA2E0C08DE50AE330@DM6PR05MB6348.namprd05.prod.outlook.com> <0f85212d-fac7-47ea-a608-4f53061cbf02@Spark> <DM6PR05MB63480E863599BBC810BF334AAE300@DM6PR05MB6348.namprd05.prod.outlook.com> <CABNhwV2+jhjAfxq5FzaukdhCOqXvGCkv75xYWcStN=SCrpni4Q@mail.gmail.com> <f4fdff8b-fe11-cb75-3cd7-7766baedf730@cisco.com> <CB2F6A55-B231-4A2D-821C-D3F2ABE6649E@futurewei.com> <cfae6af4-23d0-44b0-8bb3-f5e631b4c805@Spark>
In-Reply-To: <cfae6af4-23d0-44b0-8bb3-f5e631b4c805@Spark>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 02 Oct 2020 20:14:00 -0400
Message-ID: <CABNhwV3MmJeVMhGHqyGzwshSYVijquGsxaNFaryu5mF3j8n_zA@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Yingzhen Qu <yingzhen.qu@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f04ac405b0b92041"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/udmzQIedbkPN_-mZ6AgLp5YOFr0>
Subject: Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
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: Sat, 03 Oct 2020 00:14:15 -0000

Hi  Jeff

>From a domain perspective where you have a group of nodes and associated IP
addressed and SID are part of a discrete underlay instance flex algo
topology.  On those same set of nodes you could have another topology and
associated address and SIDs for a different flex algo.  How this would work
is that the topologies would have to be segregated from each other as
different MT instances or routing process instances.  Is that correct?

Can two nodes that run two different flex algo become ospf or isis
neighbors?

Kind Regards

Gyan

On Fri, Oct 2, 2020 at 6:25 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
> Hi Yingzhen,
>
>
>
>
>
> Yes, that’s the case.  The most important property of an algo computed
> path is that is has to be consecutive, as either SID or IP address
> associated with a particular topology is only known within that topology.
>
>
> Looking specifically at Ron’s draft (MPLS could be more complex due to
> potential hierarchy) - the prefix itself defines the context(topology) and
> must be globally unique, since IPv4 header can’t have any additional
> meta-data attached.
>
>
>
>
>
>
>
> Cheers,
>
> Jeff
>
>
>
>
>
>
> On Oct 2, 2020, 1:15 PM -0700, Yingzhen Qu <yingzhen.qu@futurewei.com>,
> wrote:
>
>
> Hi Peter,
>
>
>
>
>
> My understanding of flex-algo is that for traffic destined to a prefix on
> a particular algo, it can only be routed on routers belong to that algo,
> which also means only routers in that algo calculates how to reach that
> prefix and install it into the routing table. It seems to me that using
> flex-algo (section 12 of the draft) it's possible to have a loopback
> address associated with only one algo, please correct me if I'm missing or
> misunderstood something.
>
>
>
>
>
> Thanks,
>
>
> Yingzhen
>
>
>
>
>
> On 10/2/20, 9:43 AM, "Lsr on behalf of Peter Psenak" <
> lsr-bounces@ietf.org on behalf of ppsenak=40cisco.com@dmarc.ietf.org>
> wrote:
>
>
>
>
>
> Gyan,
>
>
>
>
>
> On 02/10/2020 18:30, Gyan Mishra wrote:
>
>
> All,
>
>
>
>
>
> With SRv6 and IP based flex algo a generic question as it applies to
>
>
> both. Is it possible to have within a single IGP domain different sets
>
>
> of nodes or segments of the network running different algorithms.
>
>
>
>
>
>
> absolutely.
>
>
>
>
>
> From
>
>
> both drafts it sounds like all nodes have to agree on same algorithm
>
>
> similar to concept of metric and reference bandwidth all have to have
>
>
> the same style metric and play to the same sheet of music.
>
>
>
>
>
>
> all participating nodes need to agree on the definition of the flex-algo
>
>
> and advertise the participation. That's it.
>
>
>
>
>
> If there was
>
>
> a way to use multiple algorithms simultaneously based on SFC or services
>
>
> and instantiation of specific algorithm based on service to be
>
>
> rendered. Doing so without causing a routing loop or sub optimal
>
>
> routing.
>
>
>
>
>
>
> you can certainly use multiple algorithms simultaneously and use algo
>
>
> specific paths to forward specific traffic over it. How that is done
>
>
> from the forwarding perspective depends in which forwarding plane you
>
>
> use. Flex-algo control plane is independent of the forwarding plane.
>
>
>
>
>
>
>
>
> I thought with flex algo that there exists a feature that on
>
>
> each hop there is a way to specify which algo to use hop by hop similar
>
>
> to a hop by hop policy based routing.
>
>
>
>
>
>
> no, there is no hop-by-hop classification, that is problematic and does
>
>
> not scale for high speeds. Classification is done at the ingress only.
>
>
>
>
>
> thanks,
>
>
> Peter
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
>
> Lsr mailing list
>
>
> Lsr@ietf.org
>
>
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Cyingzhen.qu%40futurewei.com%7C51dd940ab25d4ea19b1b08d866f23b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637372537869296887&amp;sdata=R%2FI%2BAUkcw12FmgDtsh%2FBOL7zLjPF%2BwwRpqwnE2Ndv%2Fg%3D&amp;reserved=0
>
>
>
>
>
>
>
>
>
>
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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