Re: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Acee Lindem (acee)]

Hi Robin,
I’m only missing your IPR declaration.
Thanks,
Acee

From: Huzhibo 
Date: Wednesday, August 3, 2022 at 11:08 PM
To: Acee Lindem , "draft-ietf-lsr-ospfv3-s...@ietf.org" 

Cc: lsr 
Subject: RE: IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt


Hi Acee,



I am not aware of any undisclosed IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt



thanks,

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:15 AM
To: draft-ietf-lsr-ospfv3-s...@ietf.org
Cc: lsr 
Subject: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

Co-authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thanks,
Acee & Chris


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

On 05/08/2022 09:42, Robert Raszuk wrote:

you advertise the algo X locator as UPA.


So as UPA is generated by ABRs now ABRs must be locator aware.


locator is a prefix, just advertised in a different TLV.



Moreover local flooding must be able to map nodes to locators and 
locators must be flooded in the underlay.


I'm not sure what is your point, locator processing is equal to any 
other prefix processing on ABR.




If one wants to tunnel flex-algo's between POPs across base (say core 
not being flex-algo aware) this is not possible to still use UPA ?


sure, in which case the protocol that runs over tunnel would be 
different than the protocol that provides the underlay for the tunnel.


Peter



Thx,
R.


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

>
> you advertise the algo X locator as UPA.
>

So as UPA is generated by ABRs now ABRs must be locator aware.

Moreover local flooding must be able to map nodes to locators and locators
must be flooded in the underlay.

If one wants to tunnel flex-algo's between POPs across base (say core not
being flex-algo aware) this is not possible to still use UPA ?

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

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 > 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 
 > >
 >
 > 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
 > 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

 >     >]
 >      >> Sent: Friday, August 5, 2022 1:55 PM
 >      >> To: Huzhibo mailto:huzh...@huawei.com> >>
 >      >> Cc: 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

 >     >]
 >       Sent: Wednesday, August 3, 2022 11:20 PM
 >       To: Huzhibo mailto:huzh...@huawei.com> >>
 >       Cc: 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 

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

[Robert Raszuk]

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  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
> > 
> >
> > 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
> > 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
> > ]
> >  >> Sent: Friday, August 5, 2022 1:55 PM
> >  >> To: Huzhibo mailto:huzh...@huawei.com>>
> >  >> Cc: 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
> > ]
> >   Sent: Wednesday, August 3, 2022 11:20 PM
> >   To: Huzhibo mailto:huzh...@huawei.com>>
> >   Cc: 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
> > 

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

[Peter Psenak]

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 



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 
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
]
 >> Sent: Friday, August 5, 2022 1:55 PM
 >> To: Huzhibo mailto:huzh...@huawei.com>>
 >> Cc: 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
]
  Sent: Wednesday, August 3, 2022 11:20 PM
  To: Huzhibo mailto:huzh...@huawei.com>>
  Cc: 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 

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

[Robert Raszuk]

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

Are you stating that BGP should advertise 100K routes 10 times with
different IP address ?

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.

Was this case discussed in any document/thread so far ?

Thx,
R.
.



On Fri, Aug 5, 2022 at 12:16 PM Peter Psenak  wrote:

> Zhibo,
>
> On 05/08/2022 05:49, Huzhibo wrote:
> > Peter:
> >
> >> -Original Message-
> >> From: Peter Psenak [mailto:ppse...@cisco.com]
> >> Sent: Friday, August 5, 2022 1:55 PM
> >> To: Huzhibo 
> >> Cc: 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]
>  Sent: Wednesday, August 3, 2022 11:20 PM
>  To: Huzhibo 
>  Cc: 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
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Zhibo,

On 05/08/2022 05:49, Huzhibo wrote:

Peter:


-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Friday, August 5, 2022 1:55 PM
To: Huzhibo 
Cc: 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]
Sent: Wednesday, August 3, 2022 11:20 PM
To: Huzhibo 
Cc: 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
https://www.ietf.org/mailman/listinfo/lsr

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

[Huzhibo]

Peter:

> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Friday, August 5, 2022 1:55 PM
> To: Huzhibo 
> Cc: 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]
> >> Sent: Wednesday, August 3, 2022 11:20 PM
> >> To: Huzhibo 
> >> Cc: 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.

> 
> > 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

> 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
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

Hi, Peter:

Extend the meaning of "LSInifinity" for indicating the unreachability will
again complex the deployment.
Comply with the original rules for "LSInifinity" in related RFCs (that is,
"bypass the SPF calculation for the prefixed that carried with this value")
will generate less back compatible issues and also enable the future usage
of "LSInfinity".
As cited in your draft:(also in RFC5305)

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
   during the normal SPF computation.  This allows advertisement of a
   prefix for purposes other than building the normal IP routing table.
   "
The "purposes" of such prefixes should be indicated explicitly by other
means, as that proposed in the PUA draft.

Best Regards

Aijun Wang
China Telecom




-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Peter Psenak
Sent: Friday, August 5, 2022 1:55 PM
To: Huzhibo 
Cc: lsr@ietf.org
Subject: Re: [Lsr] 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]
>> Sent: Wednesday, August 3, 2022 11:20 PM
>> To: Huzhibo 
>> Cc: 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.


> 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.

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
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr