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 <ppse...@cisco.com
<mailto:ppse...@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 <ppse...@cisco.com
<mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com <mailto:ppse...@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
<ppse...@cisco.com <mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>
> > <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>
<mailto:ppse...@cisco.com <mailto:ppse...@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
> <rob...@raszuk.net <mailto:rob...@raszuk.net>
<mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>
> > <mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>
<mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>>>
> > > <mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net> <mailto:rob...@raszuk.net
<mailto:rob...@raszuk.net>>
> <mailto:rob...@raszuk.net <mailto:rob...@raszuk.net>
<mailto:rob...@raszuk.net <mailto:rob...@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*
<nore...@ietf.org <mailto:nore...@ietf.org>
> <mailto:nore...@ietf.org <mailto:nore...@ietf.org>>
> > <mailto:nore...@ietf.org <mailto:nore...@ietf.org>
<mailto:nore...@ietf.org <mailto:nore...@ietf.org>>>
> > > <mailto:nore...@ietf.org
<mailto:nore...@ietf.org> <mailto:nore...@ietf.org
<mailto:nore...@ietf.org>>
> <mailto:nore...@ietf.org <mailto:nore...@ietf.org>
<mailto:nore...@ietf.org <mailto:nore...@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: <j...@juniper.net <mailto:j...@juniper.net>
<mailto:j...@juniper.net <mailto:j...@juniper.net>>
> <mailto:j...@juniper.net <mailto:j...@juniper.net>
<mailto:j...@juniper.net <mailto:j...@juniper.net>>>
> > <mailto:j...@juniper.net <mailto:j...@juniper.net>
<mailto:j...@juniper.net <mailto:j...@juniper.net>>
> <mailto:j...@juniper.net <mailto:j...@juniper.net>
<mailto:j...@juniper.net <mailto:j...@juniper.net>>>>>
> > > Cc: <a...@cisco.com <mailto:a...@cisco.com>
<mailto:a...@cisco.com <mailto:a...@cisco.com>>
> <mailto:a...@cisco.com <mailto:a...@cisco.com>
<mailto:a...@cisco.com <mailto:a...@cisco.com>>>
> > <mailto:a...@cisco.com <mailto:a...@cisco.com>
<mailto:a...@cisco.com <mailto:a...@cisco.com>>
> <mailto:a...@cisco.com <mailto:a...@cisco.com>
<mailto:a...@cisco.com <mailto:a...@cisco.com>>>>>,
> > > <iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>
> <mailto:iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>> <mailto:iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>
> <mailto:iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>>>
> > <mailto:iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>
> <mailto:iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>> <mailto:iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>
> <mailto:iesg-secret...@ietf.org
<mailto:iesg-secret...@ietf.org>>>>>,
> > > <lsr-cha...@ietf.org
<mailto:lsr-cha...@ietf.org> <mailto:lsr-cha...@ietf.org
<mailto:lsr-cha...@ietf.org>>
> <mailto:lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>
<mailto:lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>>>
> > <mailto:lsr-cha...@ietf.org
<mailto:lsr-cha...@ietf.org> <mailto:lsr-cha...@ietf.org
<mailto:lsr-cha...@ietf.org>>
> <mailto:lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>
<mailto:lsr-cha...@ietf.org <mailto:lsr-cha...@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>>>>
> > >
> >
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
