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

Peter Psenak <ppsenak@cisco.com> Wed, 20 May 2020 08:16 UTC

Return-Path: <ppsenak@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 B60093A128C for <lsr@ietfa.amsl.com>; Wed, 20 May 2020 01:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, 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 sOq-u83hTKXu for <lsr@ietfa.amsl.com>; Wed, 20 May 2020 01:16:22 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7254E3A3B83 for <lsr@ietf.org>; Wed, 20 May 2020 01:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9522; q=dns/txt; s=iport; t=1589962563; x=1591172163; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LDEi67JVoDXBwIgLJiddvtXTEIxOqQyGpoKR1AngGPw=; b=cNZAmB7zScF5W0Bh1MkXp3S7vebCd99NfeNGVK4F4GwM/yPYwOvFtdwM 5dGCdffpaSlVwSLTwwRFLpfFBdeLcnZhrUcUkS+0/kKU+sjmHZcvTkuKH 9dTcPBOLzk7/AirgdsoQVLyLFWn463MtaWrDR9XXddhp8jDmlsX7SDUmi c=;
X-IronPort-AV: E=Sophos;i="5.73,413,1583193600"; d="scan'208";a="26310132"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 May 2020 08:16:01 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 04K8G04r008644; Wed, 20 May 2020 08:16:01 GMT
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>, "lsr@ietf.org" <lsr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
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> <CABNhwV2-fH07f5iOedVgkP0-d7g=rgrVR7zV84w4VtQ+6ujzTA@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <b08f0f8e-2e0c-a259-3e92-c959bc4c3dfd@cisco.com>
Date: Wed, 20 May 2020 10:16:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CABNhwV2-fH07f5iOedVgkP0-d7g=rgrVR7zV84w4VtQ+6ujzTA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/XWpwl9Y4X3lAtMRw2DphcGW1WH8>
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: Wed, 20 May 2020 08:16:25 -0000

On 20/05/2020 00:37, Gyan Mishra wrote:
> 
> 
> 
> On Tue, May 19, 2020 at 3:38 AM Peter Psenak <ppsenak@cisco.com 
> <mailto: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.

not really. You need to have a way to forward traffic for different 
algos over different paths.

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

if you have IP prefix P1 and you want to be able to send the traffic to 
it via 3 different paths via native IPv4 network how would you do that?

> Also others mentioned is their special hooks or programming 
> required to make it work with RSVP-TE or PPR.
> 

I let RSVP experts to find a way how to use the flex-algo paths. I'm 
sure there are ways to do so :)

thanks,
Peter

> 
>      >
>      > 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>
>     <mailto: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>
>      >     <mailto: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>
>      >     <mailto:weibin.wang@nokia-sbell.com
>     <mailto:weibin.wang@nokia-sbell.com>>>
>      >     *Cc:* Ketan Talaulikar (ketant) <ketant@cisco.com
>     <mailto:ketant@cisco.com>
>      >     <mailto:ketant@cisco.com <mailto:ketant@cisco.com>>>;
>     lsr@ietf.org <mailto:lsr@ietf.org> <mailto: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>
>      >         <mailto: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>
>      >         <mailto: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>
>      >         <mailto:weibin.wang@nokia-sbell.com
>     <mailto:weibin.wang@nokia-sbell.com>>>; lsr@ietf.org
>     <mailto:lsr@ietf.org>
>      >         <mailto: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> <mailto: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>
>     <mailto: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> <mailto:Lsr@ietf.org
>     <mailto:Lsr@ietf.org>>
>      > https://www.ietf.org/mailman/listinfo/lsr____
>      >
>      >     _______________________________________________
>      >     Lsr mailing list
>      > Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto: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> <mailto:gyan.s.mishra@verizon.com
>     <mailto:gyan.s.mishra@verizon.com>>
>      >
>      >
>      >
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>