On 05/08/2022 09:24, Robert Raszuk wrote:
So how do I forward my services with SRv6 if I advertise all with single
BGP next hop /128 across N flex algos ?
services that want to use algo X forwarding need to be advertise with
service SID that is part of the algo X locator.
Assume for mapping I am attaching BGP Tunnel Attribute and signal on a
per service route which flex-algo to use.
Moreover how do I UPA some flex-algo's becoming unreachable in the case
where BGP next hop is different then flex-algo destination address ?
you advertise the algo X locator as UPA.
Peter
Thx,
R.
On Fri, Aug 5, 2022 at 3:19 PM Peter Psenak <ppse...@cisco.com
<mailto:ppse...@cisco.com>> wrote:
Robert,
On 05/08/2022 09:09, Robert Raszuk wrote:
> Peter,
>
> Side question ...
>
> Assume PE participates in 10 end to end flex-algos.
>
> However BGP advertises 100K service routes with base 0 nh
1.1.1.1/32 <http://1.1.1.1/32>
> <http://1.1.1.1/32 <http://1.1.1.1/32>>
>
> Are you stating that BGP should advertise 100K routes 10 times with
> different IP address ?
absolutely not.
>
> Note that mapping to flex-algo may not be prefix based on the
number of
> forwarding paradigms. Yet UPA seems to be only prefix based.
so far flex-algo has been documented for SR (MPLS and SRv6) and for IP
(v4/v6). For SR MPLS the algo forwarding is realized via unique algo
label, for SRv6 via unique algo locator and for IP via unique IP prefix.
If other "forwarding paradigms" want to use it, they would need to
defne
how.
UPA is about prefix reachability, or more precisely about the loss
of it.
thanks,
Peter
>
> Was this case discussed in any document/thread so far ?
>
> Thx,
> R.
> .
>
>
>
> On Fri, Aug 5, 2022 at 12:16 PM Peter Psenak
> <ppsenak=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>
<mailto:40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>>>
> wrote:
>
> Zhibo,
>
> On 05/08/2022 05:49, Huzhibo wrote:
> > Peter:
> >
> >> -----Original Message-----
> >> From: Peter Psenak [mailto:ppse...@cisco.com
<mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>]
> >> Sent: Friday, August 5, 2022 1:55 PM
> >> To: Huzhibo <huzh...@huawei.com
<mailto:huzh...@huawei.com> <mailto:huzh...@huawei.com
<mailto:huzh...@huawei.com>>>
> >> Cc: lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
> >> Subject: Re: Question about
> draft-ppsenak-lsr-igp-ureach-prefix-announce
> >>
> >> Zhibo,
> >>
> >> On 03/08/2022 21:09, Huzhibo wrote:
> >>> Hi Peter:
> >>> Please see inline.
> >>>
> >>>> -----Original Message-----
> >>>> From: Peter Psenak [mailto:ppse...@cisco.com
<mailto:ppse...@cisco.com>
> <mailto:ppse...@cisco.com <mailto:ppse...@cisco.com>>]
> >>>> Sent: Wednesday, August 3, 2022 11:20 PM
> >>>> To: Huzhibo <huzh...@huawei.com
<mailto:huzh...@huawei.com> <mailto:huzh...@huawei.com
<mailto:huzh...@huawei.com>>>
> >>>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>
> >>>> Subject: Re: Question about
> >>>> draft-ppsenak-lsr-igp-ureach-prefix-announce
> >>>>
> >>>> Hi Zhibo,
> >>>>
> >>>> On 29/07/2022 20:49, Huzhibo wrote:
> >>>>> Hi Peter:
> >>>>>
> >>>>> Supplement to yesterday's online questions, If a node that
> does not
> >>>>> support IP Flexalgo, which has a default route, should
the node
> >>>>> process the IP Flexalgo prefix as a UPA?
> >>>>
> >>>> - I assume you are talking about the algo 0 default route.
> Because IP
> >>>> Flex-algo default route does not make much sense really.
> >>>>
> >>>> - If the node does not support IP flex-algo, than it
would not use
> >>>> any IP algo prefix as BGP service endpoint or for any other
> purpose.
> >>>>
> >>>
> >>> Which IP Algo prefix as BGP service endpoint is not
determined
> by the ingress
> >> node, Such as VXLAN and SRv6 VPN.
> >>> When the ingress node receives an BGP Service cayyied a
IP algo
> prefix
> >>> as endpoint and it has a algo 0 default route, it should be
> process this BGP
> >> service. and this can not be affected by the IGP Flexalgo
prefix.
> >>
> >> sorry, but above is completely wrong.
> >>
> >> When you want to use IP flex-algo forwarding, you must
advertise
> the prefix as
> >> algo prefix, relying on the algo 0 default would not give you
> algo forwarding.
> >>
> >> Advertising IP algo prefix at the egress and relying in
algo 0
> default at the
> >> ingress is going to cause all sorts of problems. You CAN NOT
> mix/change algos
> >> along the path through the network - if you do, you may
end up
> in a permanent
> >> loop.
> >
> > If the ingress node does not support Flexalgo, the ingress
> node does not cause a
> > permanent loop because once the packet is forwarded to the
> Flexalgo node, it always
> > follows Flexalgo forwarding. If the packet does not reach the
> Flexalgo node, it always follows
> > Algo 0 forwarding.
>
> well, flex-algo was design for end to end forwarding.
Switching between
> algos as packet traverses the network is not guaranteed to be
loop
> free.
> If you don't trust me, I let you figure that out yourself
when you do
> such a thing and it breaks.
>
> >
> >>
> >>> Therefore,
> >>> the IGP does only not generate the RIB/Fib for LSinfinity
> Metric prefix, but can
> >> not trigger BGP Service Down.
> >>> In addition, LSinfinity Metric may be applied to other
scenarios in
> >>> the future. We cannot guarantee that LSinfinity Metric
will not
> conflict with
> >> other purposes when being processed as a UPA.
> >>
> >> no, it can not, because the LSinfinity has a very strict
> definition - it means
> >> unreachable, which is exactly what the UPA is about.
> >>
> > I believe you are confusing a concept. The LSInfinity metric
> defined in RFC 5308
> > can be considered as zero route, but PUA/UPA actually
defines a
> negative route.
> > It's not consistent
>
> I'm not confusing anything:
>
> rfc2328:
>
> LSInfinity
> The metric value indicating that the destination
described
> by an
> LSA is unreachable.
>
> regards,
> Peter
>
>
>
> >
> >> Peter
> >>
> >>>
> >>>> - If such node receives the IP algo prefix and even if it
> treats it
> >>>> as UPA, given that such IP algo prefix was never reachable
> before on
> >>>> this node, the UPA would result in no action.
> >>>>
> >>>> thanks,
> >>>> Peter
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Zhibo
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
>
> _______________________________________________
> Lsr mailing list
> 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>>
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
