Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-00.txt

Peter Psenak <ppsenak@cisco.com> Sun, 22 August 2021 13:43 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 E1C173A28C4 for <lsr@ietfa.amsl.com>; Sun, 22 Aug 2021 06:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.098
X-Spam-Level:
X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_NONE=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 m3xsVcc13u1t for <lsr@ietfa.amsl.com>; Sun, 22 Aug 2021 06:43:10 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70C53A28BD for <lsr@ietf.org>; Sun, 22 Aug 2021 06:43:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1853; q=dns/txt; s=iport; t=1629639790; x=1630849390; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/alVMXBruRvlXCWjP/o+NhaPSm35JR6/zGf9NwP1THA=; b=IF67RBXzPga3YzSDzIJvFHDIPaCbKeoVaeaUQo7/etxhCjxGH8GLBMia bOUxzb3bDQOra4pKnjBUybxQp7bSm9rsrD0wRL+dvtCbf/VcTdiyzVQ0g XUpUu00E3BBAaLjzN/QbG3ReCcTQUnO6DIEOmJMq1WAZEjUJGk4X2DVcH c=;
X-IronPort-AV: E=Sophos;i="5.84,342,1620691200"; d="scan'208";a="36635693"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Aug 2021 13:43:07 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 17MDh6XC010638; Sun, 22 Aug 2021 13:43:06 GMT
To: Robert Raszuk <robert@raszuk.net>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Ron Bonica <rbonica@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>
References: <162943024158.25012.15758140620996305842@ietfa.amsl.com> <BL0PR05MB53167201E607E5922DECA320AEC19@BL0PR05MB5316.namprd05.prod.outlook.com> <BY5PR11MB4337B66A6C77DB8FFF31DE57C1C19@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMEtOfUmGw95YownrXZ3fx_V74bWWeOqukX01j5nTM6fFg@mail.gmail.com> <BY5PR11MB4337836ED3EA8AFEB7115E07C1C19@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMGn=6s67s93mx-X59j_HWwZNE=L3FyP=dG=omfZy8q67w@mail.gmail.com> <BY5PR11MB43375E493D07444E8EFE63A0C1C29@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMEBC6oH3KWY1U0qp13d4E06Tyd14x7=fc=g7suvmkgbZw@mail.gmail.com> <BY5PR11MB433712C0E800D0F65F2C8B35C1C29@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMGJLhNUg0tOuWedi9=-kF4ND6N1bSzcNnYYrwUdx6Tw-Q@mail.gmail.com> <d7a9adf8-80fc-ef27-f666-b2ba100601ba@cisco.com> <CAOj+MMGK3oJULOZaMtDXD=qWYdE6ZvroH-p0Yh1b49trqZ0SpA@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <e49fc575-0d66-e358-0f72-f5573434fe1f@cisco.com>
Date: Sun, 22 Aug 2021 15:43:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAOj+MMGK3oJULOZaMtDXD=qWYdE6ZvroH-p0Yh1b49trqZ0SpA@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-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/8V7_C9CYQ7STDDeCZKLpWMTM1Jo>
Subject: Re: [Lsr] New Version Notification for draft-hegde-lsr-asla-any-app-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: Sun, 22 Aug 2021 13:43:17 -0000

Hi Robert,

On 22/08/2021 15:33, Robert Raszuk wrote:
> Hey Peter,
> 
>      > And I will perhaps say it again that to me flex-algo is more of a
>      > mechanism to build new applications then NEW APPLICATION itself.
> 
>     no, flex-algo is a single application, it's not a mechanism to create
>     new applications. The fact that you can create many constraints
>     topologies using flex-algo, does not mean these should be considered as
>     different apps. You have to put and keep clear borders at clear places.
>     We have them defined by ASLA and by base flex-algo draft.
> 
> 
> Why each constrained topology can not be intuitively called a different 
> network application ?


1. because flex-algo draft (which has been last called by the LSR WG 
already) defines flex-algo as a single application from the ASLA 
perspective.

2. I do not see why one would want to make application out of each 
constrained topology.

> 
> Is there any real definition of "IGP application" LSR WG has 
> converged and agreed upon ?

no, but there is a document that defines flex-algo as a single application.


> 
> See your take that it is implicitly defined in flex-algo draft by 
> setting one bit to it in SABM is IMO pretty weak. Maybe it would hold if 
> you forbid to use UDABM for flex-algo metrics, but I do not see such 
> restriction anywhere in flex-algo draft nor in ASLA drafts. That means 
> that implementation may allow it.

usage of bits in UDABM is not specified. It's user defined and not 
standardized by IETF
> 
> So flex algo is a single app if we use SABM, but it can be multiple apps 
> if we use UDABM ? Don't you think this is a bit loose definition ?

no, because the UDABM bits is not something that IETF is going to specify.

thanks,
Peter


> 
> Cheers,
> R.
>