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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> 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* <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > Date: Mon, May 16, 2022 at 3:36 PM
> > Subject: [Lsr] Publication has been requested for
> > draft-ietf-lsr-ip-flexalgo-06
> > To: <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > Cc: <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>,
> > <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>,
> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>,
> <[email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> >
> >
> > 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
> > [email protected] <mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > 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>>>
> >
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
