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

[Robert Raszuk <[e-mail]>]

Missed it - sorry:

s/ control plane CPUs and data plane FIBs / control plane CPUs and data
plane FIBs with LFA or R-LFA enabled per topo/



On Wed, May 18, 2022 at 10:53 AM Robert Raszuk <[e-mail]> 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 ?
>
> 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 <[e-mail]> 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 <[e-mail]
>> > <mailto:[e-mail]>> 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 <[e-mail]
>> >     <mailto:[e-mail]>
>> >      > <mailto:[e-mail] <mailto:[e-mail]>>> 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
>> >>
>> >      >
>> >      >     thanks,
>> >      >     Peter
>> >      >
>> >      >      >
>> >      >      > Kind regards
>> >      >      > R.
>> >      >      >
>> >      >      > On Tue, May 17, 2022 at 12:01 PM Robert Raszuk
>> >     <[e-mail] <mailto:[e-mail]>
>> >      >     <mailto:[e-mail] <mailto:[e-mail]>>
>> >      >      > <mailto:[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>>> 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* <[e-mail]
>> >     <mailto:[e-mail]>
>> >      >     <mailto:[e-mail] <mailto:[e-mail]>>
>> >      >      >     <mailto:[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>>>
>> >      >      >     Date: Mon, May 16, 2022 at 3:36 PM
>> >      >      >     Subject: [Lsr] Publication has been requested for
>> >      >      >     draft-ietf-lsr-ip-flexalgo-06
>> >      >      >     To: <[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>
>> >      >     <mailto:[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>>>
>> >      >      >     Cc: <[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>
>> >      >     <mailto:[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>>>,
>> >      >      >     <[e-mail]
>> >     <mailto:[e-mail]> <mailto:[e-mail]
>> >     <mailto:[e-mail]>>
>> >      >     <mailto:[e-mail]
>> >     <mailto:[e-mail]> <mailto:[e-mail]
>> >     <mailto:[e-mail]>>>>,
>> >      >      >     <[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>
>> >      >     <mailto:[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>>>,
>> >      >     <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>> >     <mailto:[e-mail]>>
>> >      >      >     <mailto:[e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>>>
>> >      >      >
>> >      >      >
>> >      >      >     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/>>>
>> >      >      >
>> >      >      >
>> >      >      >     _______________________________________________
>> >      >      >     Lsr mailing list
>> >      >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>> >     <mailto:[e-mail]>> <mailto:[e-mail] <mailto:[e-mail]>
>> >      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>> >      >      > 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>>>
>> >      >      >
>> >      >
>> >
>>
>>