Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Peter Psenak <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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=[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      > wrote:
>      >
>      >     Zhibo,
>      >
>      >     On 05/08/2022 05:49, Huzhibo wrote:
>      >      > Peter:
>      >      >
>      >      >> -----Original Message-----
>      >      >> From: Peter Psenak [mailto:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>]
>      >      >> Sent: Friday, August 5, 2022 1:55 PM
>      >      >> To: Huzhibo <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >> Cc: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >> 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:[e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>]
>      >      >>>> Sent: Wednesday, August 3, 2022 11:20 PM
>      >      >>>> To: Huzhibo <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >      >>>> Cc: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      >>>> 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
>      > [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>>
>      >
>