Re: [Lsr] draft-ietf-lsr-flex-algo

Gyan Mishra <hayabusagsm@gmail.com> Tue, 19 May 2020 22:37 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 A4C503A11C9 for <lsr@ietfa.amsl.com>; Tue, 19 May 2020 15:37:28 -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 Pm0VZ4LBIA8D for <lsr@ietfa.amsl.com>; Tue, 19 May 2020 15:37:26 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 692753A11C3 for <lsr@ietf.org>; Tue, 19 May 2020 15:37:26 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id j3so1079145ilk.11 for <lsr@ietf.org>; Tue, 19 May 2020 15:37:26 -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=RFTtsYir5yoL1UYWvUdvBwD/i2Y5DRnXL/q2BR7Uqfs=; b=BvwBW9n+A6DFxmkjQKUJmUS10nc/qmCX8ph2oW/nOSbL32GO+BchLkWreVV6e2s2vt 3dFejQ2twAHkQcnXq6Nb8xnh+D0Ig3MF9gbXCg5eFBAR4qT6nRNeYk5nM4+ofcYzQGgo /J2Ab2z1wnx04CSXgiOOdsaZa39NgzUmu1iTNhPIHgRNrt2bfM2vkHx339bDwP9bIhw8 ZJIANID0RNHBCYxGqCaQLpO8jtaj81geU1zz7eRLN+bjnFQ/7rxxALbkMu2n6qvQE03J K2KCicx8WxjrwzYwuRrbxhbg35wi60ROs29bcqD7TDpfSMyC75ZGRFhXxtWmg35AiunU eavw==
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=RFTtsYir5yoL1UYWvUdvBwD/i2Y5DRnXL/q2BR7Uqfs=; b=fOv/ym+ofqBzOx6B2DvExFePec5TEkLLF/Giis/j2NOHfPMSktwyZBhd29zadlfFol U6lJcS3s5E99/6hdIVSWVJALZZQa9m2FzfxUdSfZ52lVdo4QtsXZZlMaZag9LI8OpRqz oG6lLqllqxwBUHB/UhW5I1RdHnUJhdUaBdam2zZd2ZXhhXiOQbAHnQsTLkRbIwvNrmFL WJujqOZKeG6JbiiAG8o+oSY5UXuClurDE+Bij+AYU9dvkJG2/BMHPd//nvpNr9HMPiBs c8P5ivQkqfRDZx8XDcsO3434kqWrsKntpJVRaitWMIIxIyz10PMqbpyq8jx7R3SHysrE 2LUA==
X-Gm-Message-State: AOAM531GZ8SsOfUsj64/ty97EHgyW3+9q6iWKdfQzJUisWVASF4VrCBg qs1IJ472aUMH5ME+pt5VPEUiiP90XFus7UGWa9g=
X-Google-Smtp-Source: ABdhPJx5F+kZLguorQEIvucyuXgPCHS9kYN9Y1OmY/IGSKJyWRlzyboEjPOp9a0/7h70QiNx1YmmefAYKmZGRGDGGUM=
X-Received: by 2002:a05:6e02:e8c:: with SMTP id t12mr1341754ilj.186.1589927845470; Tue, 19 May 2020 15:37:25 -0700 (PDT)
MIME-Version: 1.0
References: <28938a998b384038b6dd513db00072cf@nokia-sbell.com> <48FED425-3613-42BD-9892-4CD6786EF1BB@gmail.com> <c142498d599848878eda62eae76ea3e9@nokia-sbell.com> <CABNhwV3qDts57XyD4B4bzwD=m9we2m+M9HJ++S8f=-=Lh6+pXQ@mail.gmail.com> <17654e27-0efa-bcff-67ba-01541ebc350d@cisco.com>
In-Reply-To: <17654e27-0efa-bcff-67ba-01541ebc350d@cisco.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 19 May 2020 18:37:14 -0400
Message-ID: <CABNhwV2-fH07f5iOedVgkP0-d7g=rgrVR7zV84w4VtQ+6ujzTA@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000072a66105a607ecd8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/f0moaZfXyqAG6QSniWLLe0cWCi0>
Subject: Re: [Lsr] draft-ietf-lsr-flex-algo
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, 19 May 2020 22:37:29 -0000

On Tue, May 19, 2020 at 3:38 AM Peter Psenak <ppsenak@cisco.com> wrote:

> Gyan,
>
> On 19/05/2020 03:52, Gyan Mishra wrote:
> >
> > Flex algo is usually mentioned in the context of SR-TE to help reduced
> > SRH size to circumvent MSD issues for both SRV6 and SR-MPLS,
>
> though segment list reduction may be seen as one of the benefits of the
> flex-algo, it is certainly not the primary motivation behind it. The
> primary motivation of flex-algo is to provide dynamic any to any
> constrained based routing.
>
> > however can
> > the 0-127 flex algo extensions since it’s an IGP extension used in any
> > pure IP network independent of SR flavors SR-MPLS or SRv6.
>
> SR/SRv6 is used as a dataplane. Any data plane can be used, if it
> provides a way to route an algo specific traffic.
>

    Gyan> Please clarify.  I would think that since the flex algo
capability is part of the IGP independent of the data plane is what you are
saying, so any data plane can use the feature.

So you are saying even if it can that their maybe a data plane specific
algo awareness to be able to use or route the algo specific traffic.  So
for example can native IPv4 or IPv6 date plane can it without any specific
algo awareness can it utilitize flex algo constraint based steering.  Also
others mentioned is their special hooks or programming required to make it
work with RSVP-TE or PPR.

>
> >
> > Also can flex algo be used in conjunction with RSVP-TE or PPR(preferred
> > path routing).
>
> same answer as above.
>
> thanks,
> Peter
>
> >
> > Kind regards
> >
> > Gyan
> >
> > On Sat, May 9, 2020 at 9:25 PM Wang, Weibin (NSB - CN/Shanghai)
> > <weibin.wang@nokia-sbell.com <mailto:weibin.wang@nokia-sbell.com>>
> wrote:
> >
> >     Jeff, I see what you said, thank you for sharing information;____
> >
> >     __ __
> >
> >     __ __
> >
> >     __ __
> >
> >     Cheers!
> >
> >     ____
> >
> >     __ __
> >
> >     Wang Weibin____
> >
> >     __ __
> >
> >     *From:* Jeff Tantsura <jefftant.ietf@gmail.com
> >     <mailto:jefftant.ietf@gmail.com>>
> >     *Sent:* 2020年5月10日 3:24
> >     *To:* Wang, Weibin (NSB - CN/Shanghai) <weibin.wang@nokia-sbell.com
> >     <mailto:weibin.wang@nokia-sbell.com>>
> >     *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com
> >     <mailto:ketant@cisco.com>>; lsr@ietf.org <mailto:lsr@ietf.org>
> >     *Subject:* Re: [Lsr] draft-ietf-lsr-flex-algo____
> >
> >     __ __
> >
> >     Weibin,____
> >
> >     __ __
> >
> >     One could have an algo with MSD/ERLD as optimizations constrains,
> >     would be quite similar to colored links. Note - ERLD has implemented
> >     node capabilities only, so all links on a node will have to be
> >     pruned.____
> >
> >     The tradeoffs are - having centralized controller with global view
> >     computing a path that meets the constraints(classical BGP-LS + PCEP
> >     scenario) vs building a dynamic topology of connected nodes that
> >     meet a set of constrains, in first case, change in
> >     topology/capabilities would cause path recalculation/reoptimization
> >     on the PCE while in the second - IGP would recompute the topology
> >     locally.____
> >
> >     __ __
> >
> >     Regards,____
> >
> >     Jeff____
> >
> >
> >
> >     ____
> >
> >         On May 9, 2020, at 01:27, Wang, Weibin (NSB - CN/Shanghai)
> >         <weibin.wang@nokia-sbell.com
> >         <mailto:weibin.wang@nokia-sbell.com>> wrote:____
> >
> >         ____
> >
> >         Ketan, thank you for clarification.____
> >
> >         ____
> >
> >         ____
> >
> >         ____
> >
> >         Cheers!____
> >
> >         ____
> >
> >         Wang Weibin____
> >
> >         ____
> >
> >         *From:* Ketan Talaulikar (ketant) <ketant@cisco.com
> >         <mailto:ketant@cisco.com>>
> >         *Sent:* 2020年5月9日 14:52
> >         *To:* Wang, Weibin (NSB - CN/Shanghai)
> >         <weibin.wang@nokia-sbell.com
> >         <mailto:weibin.wang@nokia-sbell.com>>; lsr@ietf.org
> >         <mailto:lsr@ietf.org>
> >         *Subject:* RE: draft-ietf-lsr-flex-algo____
> >
> >         ____
> >
> >         Hi Wang,____
> >
> >         ____
> >
> >         You are correct. Though I wouldn’t call it a goal but rather a
> >         benefit/advantage – same applies to SR-MPLS where the label
> >         stack can be reduced.____
> >
> >         ____
> >
> >         Thanks,____
> >
> >         Ketan____
> >
> >         ____
> >
> >         *From:* Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>>
> >         *On Behalf Of *Wang, Weibin (NSB - CN/Shanghai)
> >         *Sent:* 08 May 2020 19:07
> >         *To:* lsr@ietf.org <mailto:lsr@ietf.org>
> >         *Subject:* [Lsr] draft-ietf-lsr-flex-algo____
> >
> >         ____
> >
> >         Hi authors:____
> >
> >         ____
> >
> >         After reading through this draft lsr-flex-algo, I want to know
> >         whether there is a potential goal of this draft to reduce the
> >         SRH size with enabling flex-algo with admin group in SRv6
> >         deployment, because without flex-algo we have to have a big SRH
> >         size when the SRH include more SRv6 SIDs, if we enable flex-algo
> >         under special topology and link constraint condition, in theory
> >         we can even construct  a end to end SR path/tunnel without SRH,
> >         but it still meet TE requirement. So my question is whether the
> >         flex-algo can be used as tool to reduce SRH size?____
> >
> >         ____
> >
> >         ____
> >
> >         ____
> >
> >         /Cheers !/____
> >
> >         **____
> >
> >         *WANG Weibin*____
> >
> >         _______________________________________________
> >         Lsr mailing list
> >         Lsr@ietf.org <mailto:Lsr@ietf.org>
> >         https://www.ietf.org/mailman/listinfo/lsr____
> >
> >     _______________________________________________
> >     Lsr mailing list
> >     Lsr@ietf.org <mailto:Lsr@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/lsr
> >
> > --
> >
> > Gyan  Mishra
> >
> > Network Engineering & Technology
> >
> > Verizon
> >
> > Silver Spring, MD 20904
> >
> > Phone: 301 502-1347
> >
> > Email: gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>
> >
> >
> >
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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