IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Wed, 18 May 2022 11:18 UTC

Return-Path: <robert@raszuk.net>
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 67459C14F744 for <lsr@ietfa.amsl.com>; Wed, 18 May 2022 04:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 d54POpblUSkY for <lsr@ietfa.amsl.com>; Wed, 18 May 2022 04:18:18 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11056C14EB1F for <lsr@ietf.org>; Wed, 18 May 2022 04:18:17 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id i186so1631119vsc.9 for <lsr@ietf.org>; Wed, 18 May 2022 04:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZHOIoCiyeQJMP3gysNhPFQWsUz0G4xqw8mfCNLEDtgs=; b=QRva4isg8DGwxOU07SZougaP+VMtpzQcx3mNFedBftLtPVNub9YS1U9Ou7DYgphfWv P1GrJGjBGWUqLXGxJBhEIQBTQF2C0ReADMzFsBtT6DpUr3cVFP1q4eE5gxGbW2TS81D9 ymtB79HuD4BsbfBayct8n9cisc046w6GQXtOyO6JKfJno9k6eT5pFB58AKfeJoi5nf7o Dlnkh5N0LVnqmOaIBMUJ5pG7rCzX/P8Er24W6G6NH+Cu83dsGVxhRjNB3xci+YdytnHK 4FJ1+VFo4sEBXgXJP07amUf03de0yp4e1Ajru71lUMbFuK8jidC8Wqzul2kWgt3kSmhx Pnwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZHOIoCiyeQJMP3gysNhPFQWsUz0G4xqw8mfCNLEDtgs=; b=NFPzhtnVJgi0tcDnnUFjOlCqroIgHrvlU/LtEMjX15JALWWmC1ATE2FTOed+L3q1oI WwwdEKH+foIE8YOgTtCJA4loXhuBQSfqKZo4sHDb/Vzva5bjjaxhlHgtoko2FRzcN6jN CjywQGKWT421OmzFUnOe7go2t7qula0yk94bIYzd1h/VcogA6jz7Q/VRU9mgkAByRrRj xqF3mvGdpmtfSk8CA1xCKU07Dd+xUd4NuLOQzwbQO9pswb1oZiw/l5FlGJWe/wAfUjQB vIgCPrgr7aP6GpZg3WYQtG1kvfSKmZqRDtXWfPGzlVMg/ypIOs5YpdCRnVl5wmPwNBp0 u80w==
X-Gm-Message-State: AOAM532+JXB+Y4+uABTezz1xld13SuikMFOrZRbApujk7FehTLryAtnH qYsrz5wcxV97lYVBd2y8hEjokZgDPoia5oFdcjVyMTOi3UOpoQ==
X-Google-Smtp-Source: ABdhPJwvYJBNPpXLsVuk3Y2bePhorzUzPKDJA82ZMkhXRQxF/e5OCrmk7kPLoGZgQoSKvjxo3prYY9PCGBKn1YAXhpY=
X-Received: by 2002:a67:1a02:0:b0:320:a51f:8067 with SMTP id a2-20020a671a02000000b00320a51f8067mr11474426vsa.38.1652872696314; Wed, 18 May 2022 04:18:16 -0700 (PDT)
MIME-Version: 1.0
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> <1b252c7b-6b1b-f294-1f13-8119e98868a6@cisco.com>
In-Reply-To: <1b252c7b-6b1b-f294-1f13-8119e98868a6@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 18 May 2022 13:18:05 +0200
Message-ID: <CAOj+MMFRWF1VMBtwbNcFr2kmMXA0uw7EEgF2CUjVYg2--+cAsg@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ec52a305df476977"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0jeE0y6x_hR6rdDge90hp2VugWk>
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 11:18:22 -0000

Peter,

This was not my question ...

Section 10 of soon to be published RFC clearly states that *"IGP restoration
will be fast and additional protection mechanisms will not be required." *

Those "additional mechanisms" are listed further like LFA, FRR with all its
flavors which of course can be enabled in each topology.

So if (as co-author) you make such bold statement in the document I am
asking what makes networks where IGP Flex-Algo is used so good in terms of
*native* connectivity restoration that "additional protection will not be
required" ?

This is 2022 and while many folks still got locked into archaic model that
for connectivity/service restoration you need to wait for protocol
convergence I  would actually observe that during failure you should first
repair base topology then worry about flex-algos.

- - -

See one of the valid deployment models which get's often presented for
flex-algo is ability to run some special function on each node of given
topology yet make no changes whatsoever to path selection criteria. With
that running 100s of compute cycles for LFA in each topologically identical
flex-algo seems like a huge waist. And that deployment model IMO should get
attention and be addressed in base flex-algo specs.

Cheers,
Robert


On Wed, May 18, 2022 at 11:46 AM Peter Psenak <ppsenak@cisco.com> wrote:

> 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