So how do I forward my services with SRv6 if I advertise all with single BGP next hop /128 across N flex algos ?
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 ? Thx, R. On Fri, Aug 5, 2022 at 3:19 PM Peter Psenak <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> > > > > 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>> > > > wrote: > > > > Zhibo, > > > > On 05/08/2022 05:49, Huzhibo wrote: > > > Peter: > > > > > >> -----Original Message----- > > >> From: Peter Psenak [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>> > > >> Cc: 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>] > > >>>> Sent: Wednesday, August 3, 2022 11:20 PM > > >>>> To: Huzhibo <huzh...@huawei.com <mailto:huzh...@huawei.com>> > > >>>> Cc: 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> > > 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
