IETF Logo Mail Archive

Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

Peter Psenak <ppsenak@cisco.com> Wed, 18 May 2022 09:46 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 811DEC14F732 for <lsr@ietfa.amsl.com>; Wed, 18 May 2022 02:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.028
X-Spam-Level:
X-Spam-Status: No, score=-12.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.575, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.857, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuVQ-r4F9-gy for <lsr@ietfa.amsl.com>; Wed, 18 May 2022 02:46:32 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C92CBC14F723 for <lsr@ietf.org>; Wed, 18 May 2022 02:46:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17257; q=dns/txt; s=iport; t=1652867192; x=1654076792; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=XKS8egGkyD9SZ+1KCmJniutYRZZn4uf67j5aSljJGcw=; b=GLrQegGyCLFMvghWE0NG7cXLn0WsYkaOc/dudUC5vGN0k7lcEkX0COlD WrzA2AnM0vQW68vP252NNC1kaEaE4ukiUGD3xHt/4nFuCBhLri0OdjXDZ mCKG/bU+6ZqFuOWrXfvE/5JNEfms8BsUJXnoG3RYaIKQgW8acta9wlU7l s=;
X-IPAS-Result: A0AIAACLv4RilxbLJq1aHQEBAQEJARIBBQUBQIE7CAELAYMhVCsSQ4ROiCFfiAwDnGSBfAsBAQEPLA0JBAEBhQIChUAmNAkOAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBCRsGDAUON4VoDYZCAQEBAQIBAQEhDwEFLQkLEAkCEQMBAgECAiMDAgInHwkIBg0GAgEBgnkBgnMkD5BVmxd6gTGBAYNlQYNzgV8GgRAsAY5gQ4FJRIEVJ4ICUTA+gQUBgVwBAQIBgTSDf4JlBJVLKAQPAxw0OxKBIXEBCAYDAwcKBTIGAgwYFAQCExFTHQITBQcKHA4UHCQZDA8DEgMRAQcCCxIIFRMZCAMCAwgDAgMjCwIDGAkHCgMdCAocEhAUAgQTHwsIAxofLQkCBA4DQwgLCgMRBAMTGAsWCBAEBgMJLw0oCwMUDwEGAwYCBQUBAyADFAMFJwcDIQcLJg0NBBIKBx0DAwUmAwICGwcCAgMCBhcGAgJxCigNCAQIBBweJRMFAgcxBQQvAh4EBQYRCQIWAgYEBQIEBBYCAhIIAggnGwcPBxkdGQEFCVQGCwkjHAoiCwYFBhYDJmsGIgEbApIWgxgLgQQJARBbagQdGwsOAQEvIAwkBhM8AwcHH2IJCAOSFK5Tg1eEF4cEjneFZAYPBC2DdYw+hjGRdZZnjSiUaIUagWGCFTMaCBsVO4JoURkPjiwLAgmIZIVMQjE7AgYBCgEBAwmMV4JIAQE
IronPort-Data: A9a23:hcg6pay8k8rP6KPE7NR6t+d/xirEfRIJ4+MujC+fZmUNrF6WrkVWz TRLDG+FbvyPNzSnKt9/bIyz9hkCvp6DytJjSlM/rlhgHilAwSbn6Xt1DatR0we6dJCroJdPt p1GAjX4BJloCCea/H9BC5C5xZVG/fngqoHUVaiVY0ideSc+EH170U86y7Zg6mJVqYHR7z2l6 IuaT/L3YDdJ6xYsWo7Dw/vewP/HlK2aVAIw5jTSV9gS1LPtvyV94KYkGE2EByCQrr+4sQKNb 72rILmRpgs19vq2Yz+vuu6TnkYiGtY+MeUS45Zbc/DKv/RMmsA9+qQyCOhDSEhXtw6AsIEh0 doXtYWfGBh8a8UgmMxFO/VZOyhzJ+hN/6XKZCP5us2IxEqAeHzpqxlsJBhpZstDqqAtWToIr 6ZwxDMlNnhvg8qu2Km2TOBvrs8iN8LseogYvxmMyBmAUKp4GcGeK0nMze5W1gloqttJJNGdS uRHchYydhjQPBIabz/7D7pnzLv32RETaQZwrEmPjas6/2aVyxZ+uJD3N9DYYMCiX8xOjFub4 GTL4wzE7goyPdGFjDud9Wiww+nGgWXwWZkZE/uz8fsCbECvKnI7ChQqRwSarvmFsUeRCoJGJ BYU4wV/sv1nnKC0deXVUxq9qX+CmxcTXdtMDuE3gD2wJrroDxWxXTdbE2YQADAynIpnGmxwj w7hc8bBXGQ36NWopWShGqB4RA5e2BT5z0deNUforiNcvbEPRb3faDqWH76P94bv1LXI9cnYm WzikcTHr+x7YTQ3/6u650vbpDmnu4LESAU4ji2OAD//vlojPtX+OdT3gbQ+0RqmBNvHJrVml CVa8/VyEMhVZX1wvHXXGb5UTO3BCwitaWCB3jaD4KXNBxz0qyL8Iui8ERl1JVxiNY4faCT1b UrI0T69F7cNVEZGmZRfOtrrY+xzlPCIPY28Cpj8M4ofCrAsJVTv1Hw/OiatM5XFzRFEfVcXY szAL65BzB8yVMxa8dZBb7xDje5zm3pvnDq7qFKS503P7IdyrUW9Ed8tWGZipMhghE9YiG05K +piCvY=
IronPort-HdrOrdr: A9a23:SiLun66NcHszIxi2eQPXwPnXdLJyesId70hD6qm+c203TiXqra GTdZMgpHnJYVcqKRYdcL+7VZVoLUmskKKdpLNhWYtKPzOLhILLFutfBOLZqlWKJ8S9zJ8+6U 4KScZD4bPLbWSSwfyU3OF9eOxQuOVuN8uT9J7j80s=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.91,234,1647302400"; d="scan'208";a="1546095"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 May 2022 09:46:29 +0000
Received: from [10.147.24.24] ([10.147.24.24]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 24I9kS0O014224; Wed, 18 May 2022 09:46:29 GMT
Message-ID: <1b252c7b-6b1b-f294-1f13-8119e98868a6@cisco.com>
Date: Wed, 18 May 2022 11:46:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: Robert Raszuk <robert@raszuk.net>
Cc: lsr <lsr@ietf.org>
References: <165270816129.62374.13329927223902426661@ietfa.amsl.com> <CAOj+MMGoNOLMW0r3-JpMxyGQFv6ehKR5o4w4eqWQT8VmT=MO5A@mail.gmail.com> <CAOj+MMGhe27QynC7JB2vxkiKeXxtKXJxeKzd5SeP6nHs8JL0zg@mail.gmail.com> <67113aea-3555-ce40-d0bb-05dd3d3e1ae9@cisco.com> <CAOj+MMHDT8XNmyYdYEJjT0_N9v6zHSFLTFbx=ssokim6i4w1qQ@mail.gmail.com> <1aa46d51-b8c1-2e43-16f6-16063ef41b50@cisco.com> <CAOj+MMG_cLN2DE6Q4RBQ310XjFVkUCTWWD--K_xxnBADRcVcQQ@mail.gmail.com> <48f48cbf-3743-1ec8-03ff-c45d9a718cfa@cisco.com> <CAOj+MMGiekuGOdYs2fzMo1-pFg6qJNXuG5ozbOnz_b2DLGY8Kw@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
In-Reply-To: <CAOj+MMGiekuGOdYs2fzMo1-pFg6qJNXuG5ozbOnz_b2DLGY8Kw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.147.24.24, [10.147.24.24]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/uGOp4XaTfx9KEf6Rl886QfQP268>
Subject: Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.34
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, 18 May 2022 09:46:36 -0000

Robert,

On 18/05/2022 10:53, Robert Raszuk wrote:
> Peter,
> 
> It is not about someone thinking if this is a good idea or not. It is 
> about practical aspects of real deployments.
> 
> But ok section 10 of the subject draft says something pretty interesting:
> 
> /10.  Protection
> 
>     In many networks where IGP Flexible Algorithms are deployed, IGP
>     restoration will be fast and additional protection mechanisms will
>     not be required.
> /
> 
> *Question:* What makes networks with IGP flex-algo running any better 
> then networks without it in terms of protection needed or not ?

the protection is provided withing the same algo, not between them. And 
one can use all existing LFA mechanisms to do so.

thanks,
Peter


> 
> Sure when applicable ECMP can be used to locally protect the traffic. 
> But when you need to run flex-algo for mobile slicing requirements (as 
> discussed in section 3) the load on control plane CPUs and data plane 
> FIBs may become significant (especially when we are talking about lots 
> of "slices").
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, May 18, 2022 at 9:45 AM Peter Psenak <ppsenak@cisco.com 
> <mailto:ppsenak@cisco.com>> wrote:
> 
>     Robert,
> 
>     I really do not want to get into fallback between algorithms. If
>     someone
>     really thinks it is a good idea, he can write a separate document and
>     describe the use case and how to do that safely. But please not in the
>     base flex-algo specification.
> 
>     thanks,
>     Peter
> 
> 
> 
>     On 17/05/2022 19:58, Robert Raszuk wrote:
>      > Hi Peter,
>      >
>      > Enabling local protection on all nodes in all topologies may also
>     not be
>      > the best thing to do (for various reasons).
>      >
>      > While I agree that general fallback may be fragile, how about
>     limited
>      > fallback and only to one special "protection topology" which
>     would have
>      > few constraints allowing us to do such fallback safely ?
>      >
>      > I guess for ip flex-algo which is a subject of this thread this
>     would
>      > not be possible, but for SR flex-algo I think this may work
>     pretty well
>      > allowing N:1 fast connectivity restoration.
>      >
>      > Thx,
>      > Robert
>      >
>      > On Tue, May 17, 2022 at 2:19 PM Peter Psenak <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>
>      > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote:
>      >
>      >     Robert,
>      >
>      >     On 17/05/2022 14:14, Robert Raszuk wrote:
>      >      > Ok cool - thx Peter !
>      >      >
>      >      > More general question - for any FlexAlgo model (incl. SR):
>      >      >
>      >      > Is fallback between topologies - say during failure of
>     primary one -
>      >      > only allowed on the ingress to the network ?
>      >
>      >     no. Fallback between flex-algos has never been a requirement
>     and is not
>      >     part of the flex-algo specification.
>      >
>      >     I consider it a dangerous thing to do. It may work under certain
>      >     conditions, but may cause loops under different ones.
>      >
>      >     thanks,
>      >     Peter
>      >
>      >
>      >      >
>      >      > If so the repair must be setup on each topology, otherwise
>     repair
>      >     will
>      >      > be long as it would need to wait for igp flooding and ingress
>      >     switchover
>      >      > trigger ?
>      >      >
>      >      > Obviously for IP flex algo it would be much much longer as
>     given
>      >     prefix
>      >      > needs to be completely reflooded network wide and purged from
>      >     original
>      >      > topo. Ouch considering time to trigger such action.
>      >      >
>      >      > Many thanks,
>      >      > R.
>      >      >
>      >      > On Tue, May 17, 2022, 13:35 Peter Psenak
>     <ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>      >      > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>>> wrote:
>      >      >
>      >      >     Hi Robert,
>      >      >
>      >      >
>      >      >     On 17/05/2022 12:11, Robert Raszuk wrote:
>      >      >      >
>      >      >      > Actually I would like to further clarify if
>     workaround 1
>      >     is even
>      >      >     doable ...
>      >      >      >
>      >      >      > It seems to me that the IP flexalgo paradigm
>     does not have
>      >     a way for
>      >      >      > more granular then destination prefix forwarding.
>      >      >
>      >      >     that is correct. In IP flex-algo the prefix itself is
>     bound
>      >     to the
>      >      >     algorithm.
>      >      >
>      >      >      >
>      >      >      > So if I have http traffic vs streaming vs voice
>     going to
>      >     the same
>      >      >     load
>      >      >      > balancer (same dst IP address) there seems to be no
>     way to
>      >     map some
>      >      >      > traffic (based on say port number) to take specific
>     topology.
>      >      >
>      >      >     no, you can not do that with IP flex-algo.
>      >      >
>      >      >
>      >      >      >
>      >      >      > That's pretty coarse and frankly very limiting for
>      >     applicability
>      >      >     of IP
>      >      >      > flex-algo. If I am correct the draft should be very
>      >      >     explicit about this
>      >      >      > before publication.
>      >      >
>      >      >     please look at the latest version of the draft, section 3:
>      >      >
>      >      >
>      >      >
>      >
>     https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3
>     <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3>
>      >   
>       <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3>>
>      >      >
>      >     
>       <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3 <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3>>>
>      >      >
>      >      >     thanks,
>      >      >     Peter
>      >      >
>      >      >      >
>      >      >      > Kind regards
>      >      >      > R.
>      >      >      >
>      >      >      > On Tue, May 17, 2022 at 12:01 PM Robert Raszuk
>      >     <robert@raszuk.net <mailto:robert@raszuk.net>
>     <mailto:robert@raszuk.net <mailto:robert@raszuk.net>>
>      >      >     <mailto:robert@raszuk.net <mailto:robert@raszuk.net>
>     <mailto:robert@raszuk.net <mailto:robert@raszuk.net>>>
>      >      >      > <mailto:robert@raszuk.net
>     <mailto:robert@raszuk.net> <mailto:robert@raszuk.net
>     <mailto:robert@raszuk.net>>
>      >     <mailto:robert@raszuk.net <mailto:robert@raszuk.net>
>     <mailto:robert@raszuk.net <mailto:robert@raszuk.net>>>>> wrote:
>      >      >      >
>      >      >      >     Folks,
>      >      >      >
>      >      >      >     A bit related to Aijun's point but I have
>     question to
>      >      >     the text from
>      >      >      >     the draft he quoted:
>      >      >      >
>      >      >      >         In cases where a prefix advertisement is
>     received
>      >     in both
>      >      >     a IPv4
>      >      >      >         Prefix Reachability TLV and an IPv4
>     Algorithm Prefix
>      >      >     Reachability
>      >      >      >         TLV, the IPv4 Prefix Reachability advertisement
>      >     MUST be
>      >      >     preferred
>      >      >      >         when installing entries in the forwarding
>     plane.
>      >      >      >
>      >      >      >     Does this really mean that I can not for a given
>      >     prefix say
>      >      >     /24 use
>      >      >      >     default topology for best effort traffic and
>     new flex-algo
>      >      >     topology
>      >      >      >     for specific application ?
>      >      >      >
>      >      >      >     Is the "workaround 1" to always build two new
>      >     topologies for such
>      >      >      >     /24 prefix (one following base topo and one
>     new) and never
>      >      >     advertise
>      >      >      >     it in base topology ?
>      >      >      >
>      >      >      >     Is the "workaround 2" to forget about native
>      >     forwarding and
>      >      >     use for
>      >      >      >     example SR and mark the packets such that SID pool
>      >      >     corresponding to
>      >      >      >     base topology forwarding will be separate from
>     SID pool
>      >      >      >     corresponding to new flex-algo topology ?
>      >      >      >
>      >      >      >     Many thx,
>      >      >      >     Robert
>      >      >      >
>      >      >      >
>      >      >      >     ---------- Forwarded message ---------
>      >      >      >     From: *Acee Lindem via Datatracker*
>     <noreply@ietf.org <mailto:noreply@ietf.org>
>      >     <mailto:noreply@ietf.org <mailto:noreply@ietf.org>>
>      >      >     <mailto:noreply@ietf.org <mailto:noreply@ietf.org>
>     <mailto:noreply@ietf.org <mailto:noreply@ietf.org>>>
>      >      >      >     <mailto:noreply@ietf.org
>     <mailto:noreply@ietf.org> <mailto:noreply@ietf.org
>     <mailto:noreply@ietf.org>>
>      >     <mailto:noreply@ietf.org <mailto:noreply@ietf.org>
>     <mailto:noreply@ietf.org <mailto:noreply@ietf.org>>>>>
>      >      >      >     Date: Mon, May 16, 2022 at 3:36 PM
>      >      >      >     Subject: [Lsr] Publication has been requested for
>      >      >      >     draft-ietf-lsr-ip-flexalgo-06
>      >      >      >     To: <jgs@juniper.net <mailto:jgs@juniper.net>
>     <mailto:jgs@juniper.net <mailto:jgs@juniper.net>>
>      >     <mailto:jgs@juniper.net <mailto:jgs@juniper.net>
>     <mailto:jgs@juniper.net <mailto:jgs@juniper.net>>>
>      >      >     <mailto:jgs@juniper.net <mailto:jgs@juniper.net>
>     <mailto:jgs@juniper.net <mailto:jgs@juniper.net>>
>      >     <mailto:jgs@juniper.net <mailto:jgs@juniper.net>
>     <mailto:jgs@juniper.net <mailto:jgs@juniper.net>>>>>
>      >      >      >     Cc: <acee@cisco.com <mailto:acee@cisco.com>
>     <mailto:acee@cisco.com <mailto:acee@cisco.com>>
>      >     <mailto:acee@cisco.com <mailto:acee@cisco.com>
>     <mailto:acee@cisco.com <mailto:acee@cisco.com>>>
>      >      >     <mailto:acee@cisco.com <mailto:acee@cisco.com>
>     <mailto:acee@cisco.com <mailto:acee@cisco.com>>
>      >     <mailto:acee@cisco.com <mailto:acee@cisco.com>
>     <mailto:acee@cisco.com <mailto:acee@cisco.com>>>>>,
>      >      >      >     <iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>
>      >     <mailto:iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>> <mailto:iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>
>      >     <mailto:iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>>>
>      >      >     <mailto:iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>
>      >     <mailto:iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>> <mailto:iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>
>      >     <mailto:iesg-secretary@ietf.org
>     <mailto:iesg-secretary@ietf.org>>>>>,
>      >      >      >     <lsr-chairs@ietf.org
>     <mailto:lsr-chairs@ietf.org> <mailto:lsr-chairs@ietf.org
>     <mailto:lsr-chairs@ietf.org>>
>      >     <mailto:lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org>
>     <mailto:lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org>>>
>      >      >     <mailto:lsr-chairs@ietf.org
>     <mailto:lsr-chairs@ietf.org> <mailto:lsr-chairs@ietf.org
>     <mailto:lsr-chairs@ietf.org>>
>      >     <mailto:lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org>
>     <mailto:lsr-chairs@ietf.org <mailto:lsr-chairs@ietf.org>>>>>,
>      >      >     <lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>> <mailto:lsr@ietf.org
>     <mailto:lsr@ietf.org>
>      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
>      >      >      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
>      >     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>
>     <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>>>
>      >      >      >
>      >      >      >
>      >      >      >     Acee Lindem has requested publication of
>      >      >      >     draft-ietf-lsr-ip-flexalgo-06 as Proposed
>     Standard on
>      >     behalf
>      >      >     of the
>      >      >      >     LSR working group.
>      >      >      >
>      >      >      >     Please verify the document's state at
>      >      >      >
>      > https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>
>      >     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>>
>      >      >   
>       <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>
>      >     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>>>
>      >      >      >
>      >     
>       <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>
>      >     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>>
>      >      >   
>       <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>
>      >     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>>>>
>      >      >      >
>      >      >      >
>      >      >      >     _______________________________________________
>      >      >      >     Lsr mailing list
>      >      >      > Lsr@ietf.org <mailto:Lsr@ietf.org>
>     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>> <mailto:Lsr@ietf.org
>     <mailto:Lsr@ietf.org>
>      >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>
>     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org> <mailto:Lsr@ietf.org
>     <mailto:Lsr@ietf.org>>
>      >      >     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>
>     <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>>>
>      >      >      > https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>>
>      >      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>>>
>      >      >      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>>
>      >      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>
>      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>>>>
>      >      >      >
>      >      >
>      >
>

v2.23.0 | Report a Bug | By Email