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

[Robert Raszuk <[e-mail]>]

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]> 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]>> 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
> >
> >
> >     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]>>> 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]>>>
> >      >     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]>>>
> >      >     Cc: <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>,
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>,
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>,
> >     <[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/>>
> >      >
> >      >
> >      >     _______________________________________________
> >      >     Lsr mailing list
> >      > [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>>
> >      >
> >
>
>