date:20240321

Robert,

On 21/03/2024 20:52, Robert Raszuk wrote:

Peter,

Ok I think what you are proposing is pretty granular and that is fine. 
We may still disagree if link should be used at all if there are 
errors on this link in *ANY* direction.

So my suggestion here is to have that support build in as well in the 
nodes computing the topology and not always require to flood REVERSE 
colors.

In other words a color GRAY can be injected by node B irrespective if 
errors appear in TX or RX direction of the link. And that GRAY color 
should remove the link from computation bidirectionally.

affinities have always been applied in a single direction only. We have 
defined reverse affinities so we ca apply in reverse direction.

What you suggest is to have a new affinity type, which is bidirectional. 
Given what we already have, this looks redundant to me.

thanks,
Peter

In the same time sure for those who want to remove given link only in 
one direction your proposal provides tool for that.

> In our example it is used for Rx errors only. Tx errors on B are not 
relevant for A->B traffic.

+

> I want to avoid using the link even in the case of a minimal error rate.

Well typically packet errors are expressed as counters not rates. Only 
active measurements express quality of the links as rates.

If this is just a counter then the moment it crosses threshold there 
is no return till operator or script resets this counter :)  Not very 
OPS friendly 

Thx,
R.

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

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

2024-03-21 Thread Gyan Mishra

Hi Jie

I thought about this and how applying your L2 member link extension to SR
algo would work and would it be feasible or not.

I believe subinterface would work since each subinterface has an L3 logical
IP on it so could map multiple NRPs to multiple L3 sub interfaces and that
would work as each subinterface becomes a ECMP next hop for sr algo sr-mpls
prefix sid steered path.

Let’s say for example you create a network slice and allocate a NRP ID
which maps to a subset of links that belong to a sub topology and in a case
where the subset of links have multiple link coloring being part of
multiple NRPs depicting a degree of isolation and other links let’s say
being part of a single NRP total isolation, but now wanting to be able to
extend the NRP sub topology concept to not just L3 links but L2 member
links that are part of bundles being used within the NRP SR Algo sub
topology.

SR Algo in SR-MPLS used a prefix sid next hop endpoint constraint defined
for the NRP on egress PE  with discrete label x advertise in IGP for sub
topology to be instantiated as an ECMP loose hops steered path from the SR
source node is a L3 NH construct is the problem.

SR Algo in SRv6 used a locators advertised in IGP by each nodes link
coloring for the NRP to instantiate ECMP loose hops steered path from the
SR source node along the sub topology to egress PE L3 NH locator endpoint.

The construct to build the SR Algo sub topology for both SR MPLS is L3 NH
prefix sid or SRv6 NH locator is the issue with extending SR Algo to
support L2 member links.

When you think of QOS/PHB that applies to L3 per next hop basis queuing as
well for NRP resources and not L2. Even if H-QOS was used with interfaces
and subinterfaces it would all be L3 and not L2 interfaces and
subinterfaces.

Kind Regards

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *

*M 301 502-1347*

On Thu, Mar 21, 2024 at 9:32 PM Dongjie (Jimmy)  wrote:

> Hi Peter,
>
>
>
> Please see inline:
>
>
>
> *From:* Peter Psenak 
> *Sent:* Thursday, March 21, 2024 7:39 PM
> *To:* Dongjie (Jimmy) ; Les
> Ginsberg (ginsberg) ; lsr@ietf.org;
> draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
> *Subject:* Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
>
>
>
> Hi Jie,
>
>
>
> On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
>
> Hi Les,
>
>
>
> Thanks for providing your opinion with an example.
>
>
>
> In your example, the default IGP metric is used, which is normally
> calculated based on bandwidth. While Flex-Algo can support metric types
> such as TE metric and delay.
>
>
>
> When Flex-Algo is used as the control plane of NRP, usually the metric
> types other than IGP metric would be used. We could add some notes about
> the selection of metric type to this document. In most cases per Flex-Algo
> metric type would not be needed.
>
>
>
> Your proposal of making each member link an L3 link is an alternative
> solution, while that would bring back the problems we discussed during the
> L2 bundle standardization, and can impact the network stability and
> scalability.
>
>
>
> Your second proposal (controller based path computation and construction)
> works for scenarios where strict TE-path SID-list is used to steer traffic
> into specific bundle member links on each hop, while traffic with Flex-Algo
> prefix SIDs will be mixed up and ECMP among the member links of the L3
> interface.
>
>
>
> So we do see there is a gap in using Flex-Algo to support NRP, and would
> like to hear feedbacks from the WG on possible solutions (including this
> one).
>
> there is no gap in Flex-algo. Flex-algo is a routing concept and as such
> only works on L3 constructs. That will not change.
>
> [Jie] Yes Flex-Algo is a routing concept and works on L3 topology, that is
> not changed. The gap is in using Flex-Algo for NRP in some scenarios.
>
>
>
> The problem is that you are trying to mix the routing (flex-algo) with the
> PHB/QOS. These are two different things.
>
> You can achieve PHP/QOS by marking the packet and give it a necessary
> treatment you need at each hop, e.g. reserve certain bandwidth to it, or
> even reserve a L2 bundle for it if that's what you want.
>
> [Jie] The concept of NRP is different from QoS, and QoS can be used within
> an NRP.  With SR based NRPs, SR SIDs are used to steer traffic to a subset
> of resources allocated to an NRP, thus Flex-Algo specific SR SID also needs
> to be able to steer traffic to the subset of resources of the associated
> NRP.
>
>
>
> Alternatively, you can classify the traffic at each hop using other
> mechanisms, but it becomes slow and problematic.
>
> [Jie] Yes people probably do not want to do per-hop classification for
> NRPs.
>
>
>
> What you propose is to overwrite the routing decision and instead of using
> the L3 outgoing interface computed based on L3 information, you install the
> specific L2 bundle member out of such L3 interface in forwatding. It works,
> because

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Bruno,

Please check inline below with KT3.


On Thu, Mar 21, 2024 at 11:28 PM  wrote:

> Hi Ketan,
>
>
>
> Please see inline [Bruno2]
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, March 21, 2024 4:19 PM
> *To:* DECRAENE Bruno INNOV/NET 
> *Cc:* Acee Lindem ; lsr ;
> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) ;
> Tony Przygienda 
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
>
> Hi Bruno,
>
>
>
> Please check inline below with KT2 for responses.
>
>
>
>
>
> On Thu, Mar 21, 2024 at 7:16 PM  wrote:
>
> Hi Ketan,
>
>
>
> Thanks for your quick reply.
>
> Please see inline [Bruno]
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, March 21, 2024 2:18 PM
> *To:* DECRAENE Bruno INNOV/NET 
> *Cc:* Acee Lindem ; lsr ;
> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) ;
> Tony Przygienda 
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
>
> Hi Bruno,
>
>
>
> Thanks for your feedback. Please check inline below for responses.
>
>
>
>
>
> On Thu, Mar 21, 2024 at 4:12 PM  wrote:
>
> Hi all,
>
>
>
> I would also welcome a clear specification of the semantics.
>
> Such that the meaning and implications are clear on both the originator
> and the receivers/consumers.
>
>
>
> e.g., from the originator standpoint:
>
> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
> (which allow for some useful features such as….)
>
> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
> (otherwise this breaks …)
>
>
>
> Please specify the CONDITIONS1.
>
>
>
> KT> Whether a prefix is anycast or not is configured by the operator. This
> spec does not require implementations to detect that a prefix that it is
> originating is also being originated from another node and hence may be an
> anycast advertisement. We can clarify the same in the document.
>
>
>
> [Bruno] As an operator, why would I configure this? What for? What are the
> possible drawbacks? (i.e., can this be configured on all prefixes
> regardless of their anycast status)
>
>
>
> KT2> If anycast property is configured on all prefixes, then it is an
> indication that none of those prefixes resolve to a unique node. That has
> consequences in terms of usage. E.g., taking the TI-LFA repair path
> use-case, we won't find the Node SID to be used to form the repair
> segment-list.
>
>
>
> [Bruno2] Given OSPFv2, by SR you mean SR-MPLS I guess. For TI-LFA, if you
> want a Node SID, why not simply picking a SID having the N flag. That’s its
> semantic. Also with SR-MPLS we don’t do much aggregation so I’m not sure to
> see use for prefix. (by prefix, I mean not a /32 address)
>

KT3> Yes, that is why we had the N flag for that specific use case. I
assume there are no concerns with the use of the N flag and its semantics.


>
>
> I would propose those points be discussed in the operation considerations
> section of this draft.
>
> In the absence of reason, this is not likely be configured IMHO.
>
>
>
> KT2> Sure. Thanks for that feedback. We can certainly do that in the
> draft. I hope this isn't blocking the adoption in your view though, right?
>
>
>
> [Bruno2] I haven’t asked for blocking the adoption. I asked for clearly
> specified semantic.
>
>
>
>
>
> e.g., from the receiver standpoint:
>
> What does this mean to have this Anycast Flag set? What properties are
> being signaled? (a priori this may be already specified by CONDITIONS1
> above)
>
>
>
> KT> In addition to the previous response, for the receiver this means that
> the same prefix MAY be advertised from more than one node (that may be
> happening now or may happen in the future). This can be clarified as well.
>
>
>
> [Bruno] OK. If this is happening now, this is a priori already visible in
> the LSDB.
>
>
>
> KT2> This is tricky. If the prefix is originated in a different domain, it
> gets tricky to determine if the prefix is anycast or dual-homed since the
> LSDB has a local area/domain view.
>
>
>
> [Bruno2] Agreed for prefix. For Node-SID you have the N-flag. Regarding
> origination in another domain, would the ABR/L1L2 node be able to detect
> this and set the anycast flag by itself?
>

KT3> It cannot if the case is of anycast originating from different
domains/areas.


>
>
> Any reason to duplicate the info (I would guess that’s easier for
> implementation but since this is not guaranteed to be implemented one would
> need to also check in the LSDB. So doubling the work).
>
>
>
> KT2> This extension brings in simplicity for the receivers provided that
> operators can configure this property.
>
>
>
> [Bruno2] aka moving the complexity to the service provider. I guess you
> would not be surprised if I prefer the other way around (have computer do
> the job instead of humans, have vendors do the job rather than operator )
> Configuring states and

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Les,

Ack - we will fix that text.

Thanks,
Ketan


On Fri, Mar 22, 2024 at 12:17 AM Les Ginsberg (ginsberg) 
wrote:

> I support adoption of this draft.
> Knowledge of whether a given prefix is Anycast has proven useful in
> existing deployments - closing this gap for OSPFv2 is a good thing to do.
>
> One editorial comment. The introduction (and abstract) states:
>
> " Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast
>and as such the same value can be advertised by multiple routers."
>
> But there is no further discussion of prefix-SID in the draft.
> I think mention of the prefix-SID should be removed.
>
> Les
>
>
> > -Original Message-
> > From: Lsr  On Behalf Of Acee Lindem
> > Sent: Tuesday, March 19, 2024 11:43 AM
> > To: lsr 
> > Cc: draft-chen-lsr-anycast-f...@ietf.org
> > Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property
> > advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
> >
> >
> > This starts the Working Group adoption call for
> draft-chen-lsr-anycast-flag.
> > This is a simple OSPFv2 maintenance draft adding an Anycast flag for IPv4
> > prefixes to align with IS-IS and OSPFv3.
> >
> > Please send your support or objection to this list before April 6th, 2024
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

2024-03-21 Thread Dongjie (Jimmy)

Hi Peter,

Please see inline:

From: Peter Psenak 
Sent: Thursday, March 21, 2024 7:39 PM
To: Dongjie (Jimmy) ; Les Ginsberg 
(ginsberg) ; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:
Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally calculated 
based on bandwidth. While Flex-Algo can support metric types such as TE metric 
and delay.

When Flex-Algo is used as the control plane of NRP, usually the metric types 
other than IGP metric would be used. We could add some notes about the 
selection of metric type to this document. In most cases per Flex-Algo metric 
type would not be needed.

Your proposal of making each member link an L3 link is an alternative solution, 
while that would bring back the problems we discussed during the L2 bundle 
standardization, and can impact the network stability and scalability.

Your second proposal (controller based path computation and construction) works 
for scenarios where strict TE-path SID-list is used to steer traffic into 
specific bundle member links on each hop, while traffic with Flex-Algo prefix 
SIDs will be mixed up and ECMP among the member links of the L3 interface.

So we do see there is a gap in using Flex-Algo to support NRP, and would like 
to hear feedbacks from the WG on possible solutions (including this one).

there is no gap in Flex-algo. Flex-algo is a routing concept and as such only 
works on L3 constructs. That will not change.

[Jie] Yes Flex-Algo is a routing concept and works on L3 topology, that is not 
changed. The gap is in using Flex-Algo for NRP in some scenarios.

The problem is that you are trying to mix the routing (flex-algo) with the 
PHB/QOS. These are two different things.

You can achieve PHP/QOS by marking the packet and give it a necessary treatment 
you need at each hop, e.g. reserve certain bandwidth to it, or even reserve a 
L2 bundle for it if that's what you want.

[Jie] The concept of NRP is different from QoS, and QoS can be used within an 
NRP.  With SR based NRPs, SR SIDs are used to steer traffic to a subset of 
resources allocated to an NRP, thus Flex-Algo specific SR SID also needs to be 
able to steer traffic to the subset of resources of the associated NRP.

Alternatively, you can classify the traffic at each hop using other mechanisms, 
but it becomes slow and problematic.

[Jie] Yes people probably do not want to do per-hop classification for NRPs.

What you propose is to overwrite the routing decision and instead of using the 
L3 outgoing interface computed based on L3 information, you install the 
specific L2 bundle member out of such L3 interface in forwatding. It works, 
because by using the L2 member of the L3 interface the traffic is forwarded to 
the same next-hop as has been calculated by the L3 routing. Nobody can stop you 
doing that locally if you wish doing so. But there is absolutely nothing you 
need from the IETF to do this. There is no need to advertise anything to do 
what you describe, as this is all a local behavior of the node. There is no 
need to add a new E-bit, and there is not even a need to advertise affinities 
for the L2 bundle members.

[Jie] To me there is not change to the routing decision in L3. The member link 
is still part of the L3 outgoing interface. And the advertisement of the bundle 
member link information is to allow the controller or the ingress node to do TE 
path computation take the individual member links into consideration, this 
aligns with the usage of the L2 bundle as defined in their RFCs.

Best regards,

Jie

I see no need for this draft.

thanks,
Peter

Best regards,
Jie

From: Les Ginsberg (ginsberg) 
Sent: Thursday, March 21, 2024 10:36 AM
To: Dongjie (Jimmy) ; 
lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
Subject: RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Jie -

Thanx for the quick response and confirming that my understanding of the intent 
of the draft is correct.

Making a routing decision when the full topology information is not provided as 
input to the Decision Process leads to incorrect or sub-optimal routing. Here 
is one simple example.

Consider the following simple topology (Layer 3 links):

B

  /   \

A   D

 \   /

C

All layer 3 links participate in Flex Algo 128.

On both B and C, the Layer 3 link to D is an L2 bundle and the total bandwidth 
of the bundle links are the same.

On link B-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 100 Mb of bandwidth.

On link C-D, the L2 bundle member assigned to the NRP associated with flex algo 
128 has 1 GB of bandwidth.

The L3 SPF associated

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

Peter,

Ok I think what you are proposing is pretty granular and that is fine. We
may still disagree if link should be used at all if there are errors on
this link in *ANY* direction.

So my suggestion here is to have that support build in as well in the nodes
computing the topology and not always require to flood REVERSE colors.

In other words a color GRAY can be injected by node B irrespective if
errors appear in TX or RX direction of the link. And that GRAY color should
remove the link from computation bidirectionally.

In the same time sure for those who want to remove given link only in one
direction your proposal provides tool for that.

> In our example it is used for Rx errors only. Tx errors on B are not
relevant for A->B traffic.

+
> I want to avoid using the link even in the case of a minimal error rate.

Well typically packet errors are expressed as counters not rates. Only
active measurements express quality of the links as rates.

If this is just a counter then the moment it crosses threshold there is no
return till operator or script resets this counter :)  Not very OPS
friendly 

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

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

2024-03-21 Thread Les Ginsberg (ginsberg)

I support adoption of this draft.
Knowledge of whether a given prefix is Anycast has proven useful in existing 
deployments - closing this gap for OSPFv2 is a good thing to do.

One editorial comment. The introduction (and abstract) states:

" Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast
   and as such the same value can be advertised by multiple routers."

But there is no further discussion of prefix-SID in the draft.
I think mention of the prefix-SID should be removed.

Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Tuesday, March 19, 2024 11:43 AM
> To: lsr 
> Cc: draft-chen-lsr-anycast-f...@ietf.org
> Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property
> advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
> 
> 
> This starts the Working Group adoption call for draft-chen-lsr-anycast-flag.
> This is a simple OSPFv2 maintenance draft adding an Anycast flag for IPv4
> prefixes to align with IS-IS and OSPFv3.
> 
> Please send your support or objection to this list before April 6th, 2024.
> 
> Thanks,
> Acee
> 
> 
> ___
> 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] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

2024-03-21 Thread bruno . decraene

Hi Ketan,

Please see inline [Bruno2]

From: Ketan Talaulikar 
Sent: Thursday, March 21, 2024 4:19 PM
To: DECRAENE Bruno INNOV/NET 
Cc: Acee Lindem ; lsr ; 
draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) ; 
Tony Przygienda 
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Bruno,

Please check inline below with KT2 for responses.

On Thu, Mar 21, 2024 at 7:16 PM 
mailto:bruno.decra...@orange.com>> wrote:
Hi Ketan,

Thanks for your quick reply.
Please see inline [Bruno]

From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Sent: Thursday, March 21, 2024 2:18 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>
Cc: Acee Lindem mailto:acee.i...@gmail.com>>; lsr 
mailto:lsr@ietf.org>>; 
draft-chen-lsr-anycast-f...@ietf.org;
 Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Tony 
Przygienda mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Bruno,

Thanks for your feedback. Please check inline below for responses.

On Thu, Mar 21, 2024 at 4:12 PM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I would also welcome a clear specification of the semantics.
Such that the meaning and implications are clear on both the originator and the 
receivers/consumers.

e.g., from the originator standpoint:
- The originator MAY advertise the Anycast Flag if CONDITIONS1 are met (which 
allow for some useful features such as….)
- The originator MUST advertise the Anycast Flag if CONDITIONS1 are met 
(otherwise this breaks …)

Please specify the CONDITIONS1.

KT> Whether a prefix is anycast or not is configured by the operator. This spec 
does not require implementations to detect that a prefix that it is originating 
is also being originated from another node and hence may be an anycast 
advertisement. We can clarify the same in the document.

[Bruno] As an operator, why would I configure this? What for? What are the 
possible drawbacks? (i.e., can this be configured on all prefixes regardless of 
their anycast status)

KT2> If anycast property is configured on all prefixes, then it is an 
indication that none of those prefixes resolve to a unique node. That has 
consequences in terms of usage. E.g., taking the TI-LFA repair path use-case, 
we won't find the Node SID to be used to form the repair segment-list.

[Bruno2] Given OSPFv2, by SR you mean SR-MPLS I guess. For TI-LFA, if you want 
a Node SID, why not simply picking a SID having the N flag. That’s its 
semantic. Also with SR-MPLS we don’t do much aggregation so I’m not sure to see 
use for prefix. (by prefix, I mean not a /32 address)

I would propose those points be discussed in the operation considerations 
section of this draft.
In the absence of reason, this is not likely be configured IMHO.

KT2> Sure. Thanks for that feedback. We can certainly do that in the draft. I 
hope this isn't blocking the adoption in your view though, right?

[Bruno2] I haven’t asked for blocking the adoption. I asked for clearly 
specified semantic.

e.g., from the receiver standpoint:
What does this mean to have this Anycast Flag set? What properties are being 
signaled? (a priori this may be already specified by CONDITIONS1 above)

KT> In addition to the previous response, for the receiver this means that the 
same prefix MAY be advertised from more than one node (that may be happening 
now or may happen in the future). This can be clarified as well.

[Bruno] OK. If this is happening now, this is a priori already visible in the 
LSDB.

KT2> This is tricky. If the prefix is originated in a different domain, it gets 
tricky to determine if the prefix is anycast or dual-homed since the LSDB has a 
local area/domain view.

[Bruno2] Agreed for prefix. For Node-SID you have the N-flag. Regarding 
origination in another domain, would the ABR/L1L2 node be able to detect this 
and set the anycast flag by itself?

Any reason to duplicate the info (I would guess that’s easier for 
implementation but since this is not guaranteed to be implemented one would 
need to also check in the LSDB. So doubling the work).

KT2> This extension brings in simplicity for the receivers provided that 
operators can configure this property.

[Bruno2] aka moving the complexity to the service provider. I guess you would 
not be surprised if I prefer the other way around (have computer do the job 
instead of humans, have vendors do the job rather than operator ) Configuring 
states and having to maintain/updates them forever is akin to a technical debt 
to me.

KT2>  Like I mentioned above, this starts to get more complicated in 
multi-domain scenarios. Perhaps we can think of this as the complexities that 
we experience in determining this property via an LSDB/topology-db that 
motivate us to bring forth this easier and more robust

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt


Hi Robert,

On 21/03/2024 18:26, Robert Raszuk wrote:

Hey Peter,


Why do we need the notion of "reverse direction" to be any
different then
the notion of forward direction from node B to A on a link ?


For a link A->B, we typically use attributes in the direction
A->B. .e.g. link delay, link affinities, etc.

The reason why we want to be able to use reverse affinities is
that for some cases, it is only B that knows about certain
properties that relates to traffic A->B. For example only B can
detect that there is a high rate of errors on that link for
incoming traffic.


That is clear from the draft and I think that extension of computation 
is useful. I am only asking about the flooding granularity.



Can't we just use the reverse metrics locally by computing node
without flooding
anything new ?


no, because we want to use the metric in the forwarding direction,
but be able to exclude link if the errors are detected on the
other side of the link in the incoming direction.


What I meant to say was not really not to flood anything .. but not to 
flood any "reverse" colors. Meaning if node B notices errors coming on 
link to node A he floods it as some color.


Then node running flex-algo can treat such flooding as reverse locally 
if instructed so.


Example: Node B sees 1000 RX CRC errors on link to A. it checks O 
it crossed threshold 999 so I flood it as color GRAY. Why there is 
need to have this flooded with notion of "reverse" that is my question ?


You need to distinguish which affinites to use in regular and which one 
in reverse direction. You can not mix them.


Let's say a node B advertises 10 different affinites for link B->A, how 
do you know which one to use in which direction?


To do what you propose you would have to advertise the direction of each 
affiniity together with the value, or somehow associate the direction 
with it upfront. I think this would be very confusing. Having a 
completely different affinity space for each direction is way simpler.





Does the "REVERSE" really means that those are RX errors as opposed to 
TX errors ?


reverse means that it should be considered in A->B direction even though 
it is advertised with B->A link.


In our example it is used for Rx errors only. Tx errors on B are not 
relevant for A->B traffic.




I think you want to differentiate the link direction and say if I see 
RX errors this link should be removed from computation A --> B, yet in 
the same time I there is no TX errors it would be fine to keep that 
link in data direction B --> A  Is this the case ?


yes, more precisely for some very sensitive traffic, I want to avoid 
using the link even in the case of a minimal error rate.


Would it be better to just declare link as crap bidirectionally ? :)


not necessarily.


thanks,

Peter




Thx,
R.




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

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

Hey Peter,

> Why do we need the notion of "reverse direction" to be any different then
> the notion of forward direction from node B to A on a link ?
>
> For a link A->B, we typically use attributes in the direction A->B. .e.g.
> link delay, link affinities, etc.
>
> The reason why we want to be able to use reverse affinities is that for
> some cases, it is only B that knows about certain properties that relates
> to traffic A->B. For example only B can detect that there is a high rate of
> errors on that link for incoming traffic.
>

That is clear from the draft and I think that extension of computation is
useful. I am only asking about the flooding granularity.

Can't we just use the reverse metrics locally by computing node without
> flooding
> anything new ?
>
> no, because we want to use the metric in the forwarding direction, but be
> able to exclude link if the errors are detected on the other side of the
> link in the incoming direction.
>

What I meant to say was not really not to flood anything .. but not to
flood any "reverse" colors. Meaning if node B notices errors coming on link
to node A he floods it as some color.

Then node running flex-algo can treat such flooding as reverse locally if
instructed so.

Example: Node B sees 1000 RX CRC errors on link to A. it checks O it
crossed threshold 999 so I flood it as color GRAY. Why there is need to
have this flooded with notion of "reverse" that is my question ?

Does the "REVERSE" really means that those are RX errors as opposed to TX
errors ?

I think you want to differentiate the link direction and say if I see RX
errors this link should be removed from computation A --> B, yet in the
same time I there is no TX errors it would be fine to keep that link in
data direction B --> A  Is this the case ?

Would it be better to just declare link as crap bidirectionally ? :)

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

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Robert,

One quick response inline below with KT.


On Thu, Mar 21, 2024 at 10:37 PM Robert Raszuk  wrote:

> Hi Ketan,
>
> That is my main point. So we define something which is only local to the
> area.
>

> If this information will turn out to be very useful I am sure there is
> going to be someone proposing to leak it :)  Remember the UPA discussions ?
>

KT> Prefixes do get re-advertised (in OSPF we don't "leak" ;-)) across
areas without necessarily being summarized. As mentioned, there is no
discussion about summarization in this spec.

Thanks,
Ketan


>
> If so my real question is - should such information belong in IGP ? Or
> maybe rather in DROID (
> https://datatracker.ietf.org/doc/html/draft-li-lsr-droid) ?
>
> Honestly I am still a bit struggling to understand the need for it. And
> the draft is not very helpful ...
>
>
>
> *   The prefix may be configured as anycast and it is useful for other
>  routers to know that the advertisement is for an anycast identifier.*
>
> or
>
>
>
>
>
>
>
> *2.  Use-case   In the absence of the N-flag, the node specific prefixes
> need to be   identified from the anycast prefixs.  A prefix that is
> advertised by   a single node and without an AC-flag MUST be considered
> node   specific.*
>
> Especially the "use-case" looks to me like copy and paste error :)
>
> Thx,
> Robert
>
>
> On Thu, Mar 21, 2024 at 5:44 PM Ketan Talaulikar 
> wrote:
>
>> Hi Robert,
>>
>> Summarization/aggregation does result in loss of individual prefixes'
>> attributes.
>>
>> The draft does not intend to specify procedures for propagation of
>> anycast attribute of individual prefixes to the summary since that is not
>> something that is going to be robust.
>>
>> Thanks,
>> Ketan
>>
>>
>> On Thu, Mar 21, 2024 at 10:02 PM Robert Raszuk  wrote:
>>
>>> Hi,
>>>
>>> Isn't this knowledge gone outside of the local area when ABR does
>>> summarization ? If so, is this really practically useful ?
>>>
>>> Thx,
>>> R.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar 
>>> wrote:
>>>
 Hi Bruno,

 Please check inline below with KT2 for responses.


 On Thu, Mar 21, 2024 at 7:16 PM  wrote:

> Hi Ketan,
>
>
>
> Thanks for your quick reply.
>
> Please see inline [Bruno]
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, March 21, 2024 2:18 PM
> *To:* DECRAENE Bruno INNOV/NET 
> *Cc:* Acee Lindem ; lsr ;
> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) <
> jie.d...@huawei.com>; Tony Przygienda 
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to
> Anycast Property advertisement for OSPFv2" - 
> draft-chen-lsr-anycast-flag-06
>
>
>
> Hi Bruno,
>
>
>
> Thanks for your feedback. Please check inline below for responses.
>
>
>
>
>
> On Thu, Mar 21, 2024 at 4:12 PM  wrote:
>
> Hi all,
>
>
>
> I would also welcome a clear specification of the semantics.
>
> Such that the meaning and implications are clear on both the
> originator and the receivers/consumers.
>
>
>
> e.g., from the originator standpoint:
>
> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
> (which allow for some useful features such as….)
>
> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are
> met (otherwise this breaks …)
>
>
>
> Please specify the CONDITIONS1.
>
>
>
> KT> Whether a prefix is anycast or not is configured by the operator.
> This spec does not require implementations to detect that a prefix that it
> is originating is also being originated from another node and hence may be
> an anycast advertisement. We can clarify the same in the document.
>
>
>
> [Bruno] As an operator, why would I configure this? What for? What are
> the possible drawbacks? (i.e., can this be configured on all prefixes
> regardless of their anycast status)
>

 KT2> If anycast property is configured on all prefixes, then it is an
 indication that none of those prefixes resolve to a unique node. That has
 consequences in terms of usage. E.g., taking the TI-LFA repair path
 use-case, we won't find the Node SID to be used to form the repair
 segment-list.


> I would propose those points be discussed in the operation
> considerations section of this draft.
>
> In the absence of reason, this is not likely be configured IMHO.
>

 KT2> Sure. Thanks for that feedback. We can certainly do that in the
 draft. I hope this isn't blocking the adoption in your view though, right?


>
>
> e.g., from the receiver standpoint:
>
> What does this mean to have this Anycast Flag set? What properties are
> being signaled? (a priori this may be already specified by CONDITIONS1
> above)
>
>
>

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

Robert,

On 21/03/2024 17:52, Robert Raszuk wrote:

Hi,

> When Flex-Algorithm calculation processes the link A to B, it may
look at
> the 'colors' of the link in the reverse direction, e.g., link B to
A. This would
> allow the operator to exclude such link from the Flex-Algorithm
topology.

Why do we need the notion of "reverse direction" to be any different then
the notion of forward direction from node B to A on a link ?

For a link A->B, we typically use attributes in the direction A->B.
.e.g. link delay, link affinities, etc.

The reason why we want to be able to use reverse affinities is that for
some cases, it is only B that knows about certain properties that
relates to traffic A->B. For example only B can detect that there is a
high rate of errors on that link for incoming traffic.

Can't we just use the reverse metrics locally by computing node
without flooding

anything new ?

no, because we want to use the metric in the forwarding direction, but
be able to exclude link if the errors are detected on the other side of
the link in the incoming direction.

> An operator may measure the rate of such input errors and set
certain 'color' on a link

> locally on node B when the input error rate crosses a certain threshold.

IMO the draft should go into more detail or at least provide a pointer
to another document with description how to protect from continued
churn in propagating those colors when oscillate and go below and
above a set threshold many times per second.

the draft defines the mechanism how to advertise and use the reverse
affinities. When to set it and how frequently, is not something that
this draft specifies. Not that I disagree with you, but the same applies
to any link attribute that is used during any calculation, being it TE
or flex-algo. It's not specific to reverse affinities at all.

Then aside from reducing the propagation frequency local protection
from continued SPF runs should also be mentioned. I guess you assume
that this is in place anyway.

absolutely.

> The IS-IS Flexible Algorithm Exclude Reverse Admin Group (FAERAG)

I think "FAERAG" is very hard to say. How about just "ERAG" as an
acronym ?

whatever you like :)

thanks,
Peter

Thx,
R.

On Mon, Mar 18, 2024 at 9:12 AM wrote:

Internet-Draft
draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now
available. It is a work item of the Link State Routing (LSR) WG of
the IETF.

Title: IGP Flexible Algorithms Reverse Affinity Constraint
Authors: Peter Psenak
Jakub Horn
Amit Dhamija
Name: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
Pages: 9
Dates: 2024-03-18

Abstract:

An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
constraint-based paths.

This document extends IGP Flex-Algorithm with additional
constraints.

The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/

There is also an HTMLized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-02

A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-02

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

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

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Ketan,

That is my main point. So we define something which is only local to the
area.

If this information will turn out to be very useful I am sure there is
going to be someone proposing to leak it :)  Remember the UPA discussions ?

If so my real question is - should such information belong in IGP ? Or
maybe rather in DROID (
https://datatracker.ietf.org/doc/html/draft-li-lsr-droid) ?

Honestly I am still a bit struggling to understand the need for it. And the
draft is not very helpful ...

*   The prefix may be configured as anycast and it is useful for other
 routers to know that the advertisement is for an anycast identifier.*

or

*2.  Use-case   In the absence of the N-flag, the node specific prefixes
need to be   identified from the anycast prefixs.  A prefix that is
advertised by   a single node and without an AC-flag MUST be considered
node   specific.*

Especially the "use-case" looks to me like copy and paste error :)

Thx,
Robert

On Thu, Mar 21, 2024 at 5:44 PM Ketan Talaulikar 
wrote:

> Hi Robert,
>
> Summarization/aggregation does result in loss of individual prefixes'
> attributes.
>
> The draft does not intend to specify procedures for propagation of anycast
> attribute of individual prefixes to the summary since that is not something
> that is going to be robust.
>
> Thanks,
> Ketan
>
>
> On Thu, Mar 21, 2024 at 10:02 PM Robert Raszuk  wrote:
>
>> Hi,
>>
>> Isn't this knowledge gone outside of the local area when ABR does
>> summarization ? If so, is this really practically useful ?
>>
>> Thx,
>> R.
>>
>>
>> On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar 
>> wrote:
>>
>>> Hi Bruno,
>>>
>>> Please check inline below with KT2 for responses.
>>>
>>>
>>> On Thu, Mar 21, 2024 at 7:16 PM  wrote:
>>>
 Hi Ketan,

 Thanks for your quick reply.

 Please see inline [Bruno]

 *From:* Ketan Talaulikar 
 *Sent:* Thursday, March 21, 2024 2:18 PM
 *To:* DECRAENE Bruno INNOV/NET 
 *Cc:* Acee Lindem ; lsr ;
 draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) <
 jie.d...@huawei.com>; Tony Przygienda 
 *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to
 Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

 Hi Bruno,

 Thanks for your feedback. Please check inline below for responses.

 On Thu, Mar 21, 2024 at 4:12 PM  wrote:

 Hi all,

 I would also welcome a clear specification of the semantics.

 Such that the meaning and implications are clear on both the originator
 and the receivers/consumers.

 e.g., from the originator standpoint:

 - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
 (which allow for some useful features such as….)

 - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
 (otherwise this breaks …)

 Please specify the CONDITIONS1.

 KT> Whether a prefix is anycast or not is configured by the operator.
 This spec does not require implementations to detect that a prefix that it
 is originating is also being originated from another node and hence may be
 an anycast advertisement. We can clarify the same in the document.

 [Bruno] As an operator, why would I configure this? What for? What are
 the possible drawbacks? (i.e., can this be configured on all prefixes
 regardless of their anycast status)

>>>
>>> KT2> If anycast property is configured on all prefixes, then it is an
>>> indication that none of those prefixes resolve to a unique node. That has
>>> consequences in terms of usage. E.g., taking the TI-LFA repair path
>>> use-case, we won't find the Node SID to be used to form the repair
>>> segment-list.
>>>
>>>
 I would propose those points be discussed in the operation
 considerations section of this draft.

 In the absence of reason, this is not likely be configured IMHO.

>>>
>>> KT2> Sure. Thanks for that feedback. We can certainly do that in the
>>> draft. I hope this isn't blocking the adoption in your view though, right?
>>>
>>>

 e.g., from the receiver standpoint:

 What does this mean to have this Anycast Flag set? What properties are
 being signaled? (a priori this may be already specified by CONDITIONS1
 above)

 KT> In addition to the previous response, for the receiver this means
 that the same prefix MAY be advertised from more than one node (that may be
 happening now or may happen in the future). This can be clarified as well.

 [Bruno] OK. If this is happening now, this is a priori already visible
 in the LSDB.

>>>
>>> KT2> This is tricky. If the prefix is originated in a different domain,
>>> it gets tricky to determine if the prefix is anycast or dual-homed since
>>> the LSDB

Re: [Lsr] I-D Action: draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt

Hi,

> When Flex-Algorithm calculation processes the link A to B, it may look at
> the 'colors' of the link in the reverse direction, e.g., link B to A.
This would
> allow the operator to exclude such link from the Flex-Algorithm topology.

Why do we need the notion of "reverse direction" to be any different then
the notion of forward direction from node B to A on a link ?

Can't we just use the reverse metrics locally by computing node without
flooding
anything new ?

> An operator may measure the rate of such input errors and set certain
'color' on a link
> locally on node B when the input error rate crosses a certain threshold.

IMO the draft should go into more detail or at least provide a pointer to
another document with description how to protect from continued churn in
propagating those colors when oscillate and go below and above a set
threshold many times per second.

Then aside from reducing the propagation frequency local protection from
continued SPF runs should also be mentioned. I guess you assume that this
is in place anyway.

> The IS-IS Flexible Algorithm Exclude Reverse Admin Group (FAERAG)

I think "FAERAG" is very hard to say. How about just "ERAG" as an acronym ?

Thx,
R.


On Mon, Mar 18, 2024 at 9:12 AM  wrote:

> Internet-Draft draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt is now
> available. It is a work item of the Link State Routing (LSR) WG of the
> IETF.
>
>Title:   IGP Flexible Algorithms Reverse Affinity Constraint
>Authors: Peter Psenak
> Jakub Horn
> Amit Dhamija
>Name:draft-ietf-lsr-igp-flex-algo-reverse-affinity-02.txt
>Pages:   9
>Dates:   2024-03-18
>
> Abstract:
>
>An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
>constraint-based paths.
>
>This document extends IGP Flex-Algorithm with additional constraints.
>
> The IETF datatracker status page for this Internet-Draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/
>
> There is also an HTMLized version available at:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-igp-flex-algo-reverse-affinity-02
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-02
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> 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] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Robert,

Summarization/aggregation does result in loss of individual prefixes'
attributes.

The draft does not intend to specify procedures for propagation of anycast
attribute of individual prefixes to the summary since that is not something
that is going to be robust.

Thanks,
Ketan


On Thu, Mar 21, 2024 at 10:02 PM Robert Raszuk  wrote:

> Hi,
>
> Isn't this knowledge gone outside of the local area when ABR does
> summarization ? If so, is this really practically useful ?
>
> Thx,
> R.
>
>
> On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar 
> wrote:
>
>> Hi Bruno,
>>
>> Please check inline below with KT2 for responses.
>>
>>
>> On Thu, Mar 21, 2024 at 7:16 PM  wrote:
>>
>>> Hi Ketan,
>>>
>>>
>>>
>>> Thanks for your quick reply.
>>>
>>> Please see inline [Bruno]
>>>
>>>
>>>
>>> *From:* Ketan Talaulikar 
>>> *Sent:* Thursday, March 21, 2024 2:18 PM
>>> *To:* DECRAENE Bruno INNOV/NET 
>>> *Cc:* Acee Lindem ; lsr ;
>>> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) <
>>> jie.d...@huawei.com>; Tony Przygienda 
>>> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to
>>> Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>>>
>>>
>>>
>>> Hi Bruno,
>>>
>>>
>>>
>>> Thanks for your feedback. Please check inline below for responses.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Mar 21, 2024 at 4:12 PM  wrote:
>>>
>>> Hi all,
>>>
>>>
>>>
>>> I would also welcome a clear specification of the semantics.
>>>
>>> Such that the meaning and implications are clear on both the originator
>>> and the receivers/consumers.
>>>
>>>
>>>
>>> e.g., from the originator standpoint:
>>>
>>> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
>>> (which allow for some useful features such as….)
>>>
>>> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
>>> (otherwise this breaks …)
>>>
>>>
>>>
>>> Please specify the CONDITIONS1.
>>>
>>>
>>>
>>> KT> Whether a prefix is anycast or not is configured by the operator.
>>> This spec does not require implementations to detect that a prefix that it
>>> is originating is also being originated from another node and hence may be
>>> an anycast advertisement. We can clarify the same in the document.
>>>
>>>
>>>
>>> [Bruno] As an operator, why would I configure this? What for? What are
>>> the possible drawbacks? (i.e., can this be configured on all prefixes
>>> regardless of their anycast status)
>>>
>>
>> KT2> If anycast property is configured on all prefixes, then it is an
>> indication that none of those prefixes resolve to a unique node. That has
>> consequences in terms of usage. E.g., taking the TI-LFA repair path
>> use-case, we won't find the Node SID to be used to form the repair
>> segment-list.
>>
>>
>>> I would propose those points be discussed in the operation
>>> considerations section of this draft.
>>>
>>> In the absence of reason, this is not likely be configured IMHO.
>>>
>>
>> KT2> Sure. Thanks for that feedback. We can certainly do that in the
>> draft. I hope this isn't blocking the adoption in your view though, right?
>>
>>
>>>
>>>
>>> e.g., from the receiver standpoint:
>>>
>>> What does this mean to have this Anycast Flag set? What properties are
>>> being signaled? (a priori this may be already specified by CONDITIONS1
>>> above)
>>>
>>>
>>>
>>> KT> In addition to the previous response, for the receiver this means
>>> that the same prefix MAY be advertised from more than one node (that may be
>>> happening now or may happen in the future). This can be clarified as well.
>>>
>>>
>>>
>>> [Bruno] OK. If this is happening now, this is a priori already visible
>>> in the LSDB.
>>>
>>
>> KT2> This is tricky. If the prefix is originated in a different domain,
>> it gets tricky to determine if the prefix is anycast or dual-homed since
>> the LSDB has a local area/domain view.
>>
>>
>>> Any reason to duplicate the info (I would guess that’s easier for
>>> implementation but since this is not guaranteed to be implemented one would
>>> need to also check in the LSDB. So doubling the work).
>>>
>>
>> KT2> This extension brings in simplicity for the receivers provided that
>> operators can configure this property. Like I mentioned above, this starts
>> to get more complicated in multi-domain scenarios. Perhaps we can think of
>> this as the complexities that we experience in determining this property
>> via an LSDB/topology-db that motivate us to bring forth this easier and
>> more robust way.
>>
>>
>>> Any specific reason requiring the knowledge of the future?
>>>
>>
>> KT2> Perhaps at time T1, there are two nodes originating the prefix. Then
>> at time T2, one of them goes down (or becomes disconnected), do we assume
>> that the prefix is now not anycast? Then what happens if that other node
>> comes back up again. For certain use-cases where anycast prefix is not
>> desired, it may be helpful to completely avoid use of this prefix. The
>> operator knows their design and addressing and perhaps is able to

Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

Hi All,

I have reviewed this document and believe it needs some further work before
publication.

I am sharing my comments below:

1) There is the following text in sec 2.1 and 2.2 for Generic Metric.

A metric value of 0xFF is considered as maximum link metric and a link
having this metric value MUST NOT be used during Flex-algorithm
calculations [RFC9350

]. The link with maximum generic metric value is not available for the use
of Flexible Algorithms but is availble for other use cases.

I believe the FlexAlgo reference here is to
https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration

But the above text does not align with the RFC9350. If a link is to be made
unavailable for FlexAlgos operating with a specific Generic Metric, then
the way to do that is to omit that specific Generic Metric TLV from the
ASLA for flex-algo application. The same would apply for other applications
- just omit the metric. Why do we need a special MAX-LINK-METRIC value for
generic metric given that it is a new thing we are introducing?

2) This comment is specific to OSPF given the encoding differences it has
with ISIS. Section 2.2 allows for Generic Metric TLV to be used in too many
places without clear specification of what it is used for - this is a
potential pitfall for interop issues. RFC9492 provides helpful directions
for us here.
a) This draft specifies FlexAlgo extensions, it is natural that Generic
Metric be advertised under ASLA TLV. No issues here.
b) This draft does not specify anything about use of generic metric in base
OSPF and as a reminder there is nothing like L-bit in OSPF encoding.
Therefore, it does not make sense to advertise Generic Metric outside of
ASLA and under the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV.
c) This draft does not specify anything about use of generic metric with
RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic
Metric in the TE Opaque LSAs.
We can have specific documents that introduce (b) or (c) when there is a
proper specification.

3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a 4
octet boundary as is the convention in OSPF -
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2

4) In section 3.2.2 there is the following text for OSPF. Could you please
use the TLV/sub-TLV name? OSPF folks are not good at remembering numbers ;-)

The Min Unidirectional Link Delay as advertised by *sub-sub-TLV 12* of ASLA
sub-TLV [RFC8920

], MUST be compared against the Maximum delay advertised in the FAEMD
sub-TLV.

5) Do we want to call out that the reference bandwidth approach requires a
router to compute and maintain a per link per algo bandwidth metric for
every link in that algo topology. It may not be very obvious to some.

6) There are a lot of procedures which are common to both OSPF and ISIS and
are repeated in each section instead of a common section. It would be
easier (and avoid errors) if there was some consolidation.
https://www.rfc-editor.org/rfc/rfc9350.html#section-5 provides a good
reference for such an organization of text.

7) Regarding
https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6,
it seems like we want to retain a numbering ordering of rules/sequence for
flex-algo as extension documents are introduced. Am I correct? If so, then
this document should formally "update" RFC9350 since it is changing the
"set of rules/sequence" for FlexAlgo computations. Further such extensions
will also need to keep updating the base spec similarly. I would suggest
that a full set of rules that is a union of what is in RFC9350 and rules
added by this draft are maintained in an Appendix section. Other documents
in the future can similarly maintain the latest set of rules.

8) Please fix idnits warnings - some are related to obsolete references
while others are related to formatting. There are also some
spelling/grammar errors.

Thanks,
Ketan

On Tue, Feb 20, 2024 at 3:56 AM Acee Lindem  wrote:

>
> This starts the Working Group Last call for
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm
> enhancements described in the document have been implemented.
>
>  Please send your support or objection to this before March 5th, 2024.
>
> Thanks,
> Acee
> ___
> 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] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi,

Isn't this knowledge gone outside of the local area when ABR does
summarization ? If so, is this really practically useful ?

Thx,
R.


On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar 
wrote:

> Hi Bruno,
>
> Please check inline below with KT2 for responses.
>
>
> On Thu, Mar 21, 2024 at 7:16 PM  wrote:
>
>> Hi Ketan,
>>
>>
>>
>> Thanks for your quick reply.
>>
>> Please see inline [Bruno]
>>
>>
>>
>> *From:* Ketan Talaulikar 
>> *Sent:* Thursday, March 21, 2024 2:18 PM
>> *To:* DECRAENE Bruno INNOV/NET 
>> *Cc:* Acee Lindem ; lsr ;
>> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) <
>> jie.d...@huawei.com>; Tony Przygienda 
>> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
>> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>>
>>
>>
>> Hi Bruno,
>>
>>
>>
>> Thanks for your feedback. Please check inline below for responses.
>>
>>
>>
>>
>>
>> On Thu, Mar 21, 2024 at 4:12 PM  wrote:
>>
>> Hi all,
>>
>>
>>
>> I would also welcome a clear specification of the semantics.
>>
>> Such that the meaning and implications are clear on both the originator
>> and the receivers/consumers.
>>
>>
>>
>> e.g., from the originator standpoint:
>>
>> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
>> (which allow for some useful features such as….)
>>
>> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
>> (otherwise this breaks …)
>>
>>
>>
>> Please specify the CONDITIONS1.
>>
>>
>>
>> KT> Whether a prefix is anycast or not is configured by the operator.
>> This spec does not require implementations to detect that a prefix that it
>> is originating is also being originated from another node and hence may be
>> an anycast advertisement. We can clarify the same in the document.
>>
>>
>>
>> [Bruno] As an operator, why would I configure this? What for? What are
>> the possible drawbacks? (i.e., can this be configured on all prefixes
>> regardless of their anycast status)
>>
>
> KT2> If anycast property is configured on all prefixes, then it is an
> indication that none of those prefixes resolve to a unique node. That has
> consequences in terms of usage. E.g., taking the TI-LFA repair path
> use-case, we won't find the Node SID to be used to form the repair
> segment-list.
>
>
>> I would propose those points be discussed in the operation considerations
>> section of this draft.
>>
>> In the absence of reason, this is not likely be configured IMHO.
>>
>
> KT2> Sure. Thanks for that feedback. We can certainly do that in the
> draft. I hope this isn't blocking the adoption in your view though, right?
>
>
>>
>>
>> e.g., from the receiver standpoint:
>>
>> What does this mean to have this Anycast Flag set? What properties are
>> being signaled? (a priori this may be already specified by CONDITIONS1
>> above)
>>
>>
>>
>> KT> In addition to the previous response, for the receiver this means
>> that the same prefix MAY be advertised from more than one node (that may be
>> happening now or may happen in the future). This can be clarified as well.
>>
>>
>>
>> [Bruno] OK. If this is happening now, this is a priori already visible in
>> the LSDB.
>>
>
> KT2> This is tricky. If the prefix is originated in a different domain, it
> gets tricky to determine if the prefix is anycast or dual-homed since the
> LSDB has a local area/domain view.
>
>
>> Any reason to duplicate the info (I would guess that’s easier for
>> implementation but since this is not guaranteed to be implemented one would
>> need to also check in the LSDB. So doubling the work).
>>
>
> KT2> This extension brings in simplicity for the receivers provided that
> operators can configure this property. Like I mentioned above, this starts
> to get more complicated in multi-domain scenarios. Perhaps we can think of
> this as the complexities that we experience in determining this property
> via an LSDB/topology-db that motivate us to bring forth this easier and
> more robust way.
>
>
>> Any specific reason requiring the knowledge of the future?
>>
>
> KT2> Perhaps at time T1, there are two nodes originating the prefix. Then
> at time T2, one of them goes down (or becomes disconnected), do we assume
> that the prefix is now not anycast? Then what happens if that other node
> comes back up again. For certain use-cases where anycast prefix is not
> desired, it may be helpful to completely avoid use of this prefix. The
> operator knows their design and addressing and perhaps is able to provision
> this prefix property correctly from the outset.
>
>
>>
>>
>>
>>
>>
>>
>> If this is specific to SR,  please say so.
>>
>>
>>
>> KT> It is not specific to SR, it is a property of an IP prefix.
>>
>>
>>
>> But even in this sub-case, SR anycast has some conditions, both for
>> SR-MPLS and SRv6.
>>
>>
>>
>> KT> This document does not discuss either SR-MPLS or SRv6 anycast. It
>> covers an OSPFv2 extension to simply advertise the anycast property of any
>> IP prefix. The discussion of SR anycast

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Bruno,

Please check inline below with KT2 for responses.

On Thu, Mar 21, 2024 at 7:16 PM  wrote:

> Hi Ketan,
>
>
>
> Thanks for your quick reply.
>
> Please see inline [Bruno]
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, March 21, 2024 2:18 PM
> *To:* DECRAENE Bruno INNOV/NET 
> *Cc:* Acee Lindem ; lsr ;
> draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) ;
> Tony Przygienda 
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
>
> Hi Bruno,
>
>
>
> Thanks for your feedback. Please check inline below for responses.
>
>
>
>
>
> On Thu, Mar 21, 2024 at 4:12 PM  wrote:
>
> Hi all,
>
>
>
> I would also welcome a clear specification of the semantics.
>
> Such that the meaning and implications are clear on both the originator
> and the receivers/consumers.
>
>
>
> e.g., from the originator standpoint:
>
> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
> (which allow for some useful features such as….)
>
> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
> (otherwise this breaks …)
>
>
>
> Please specify the CONDITIONS1.
>
>
>
> KT> Whether a prefix is anycast or not is configured by the operator. This
> spec does not require implementations to detect that a prefix that it is
> originating is also being originated from another node and hence may be an
> anycast advertisement. We can clarify the same in the document.
>
>
>
> [Bruno] As an operator, why would I configure this? What for? What are the
> possible drawbacks? (i.e., can this be configured on all prefixes
> regardless of their anycast status)
>

KT2> If anycast property is configured on all prefixes, then it is an
indication that none of those prefixes resolve to a unique node. That has
consequences in terms of usage. E.g., taking the TI-LFA repair path
use-case, we won't find the Node SID to be used to form the repair
segment-list.

> I would propose those points be discussed in the operation considerations
> section of this draft.
>
> In the absence of reason, this is not likely be configured IMHO.
>

KT2> Sure. Thanks for that feedback. We can certainly do that in the draft.
I hope this isn't blocking the adoption in your view though, right?

>
>
> e.g., from the receiver standpoint:
>
> What does this mean to have this Anycast Flag set? What properties are
> being signaled? (a priori this may be already specified by CONDITIONS1
> above)
>
>
>
> KT> In addition to the previous response, for the receiver this means that
> the same prefix MAY be advertised from more than one node (that may be
> happening now or may happen in the future). This can be clarified as well.
>
>
>
> [Bruno] OK. If this is happening now, this is a priori already visible in
> the LSDB.
>

KT2> This is tricky. If the prefix is originated in a different domain, it
gets tricky to determine if the prefix is anycast or dual-homed since the
LSDB has a local area/domain view.

> Any reason to duplicate the info (I would guess that’s easier for
> implementation but since this is not guaranteed to be implemented one would
> need to also check in the LSDB. So doubling the work).
>

KT2> This extension brings in simplicity for the receivers provided that
operators can configure this property. Like I mentioned above, this starts
to get more complicated in multi-domain scenarios. Perhaps we can think of
this as the complexities that we experience in determining this property
via an LSDB/topology-db that motivate us to bring forth this easier and
more robust way.

> Any specific reason requiring the knowledge of the future?
>

KT2> Perhaps at time T1, there are two nodes originating the prefix. Then
at time T2, one of them goes down (or becomes disconnected), do we assume
that the prefix is now not anycast? Then what happens if that other node
comes back up again. For certain use-cases where anycast prefix is not
desired, it may be helpful to completely avoid use of this prefix. The
operator knows their design and addressing and perhaps is able to provision
this prefix property correctly from the outset.

>
>
>
>
>
>
> If this is specific to SR,  please say so.
>
>
>
> KT> It is not specific to SR, it is a property of an IP prefix.
>
>
>
> But even in this sub-case, SR anycast has some conditions, both for
> SR-MPLS and SRv6.
>
>
>
> KT> This document does not discuss either SR-MPLS or SRv6 anycast. It
> covers an OSPFv2 extension to simply advertise the anycast property of any
> IP prefix. The discussion of SR anycast belongs to some other (SPRING)
> document ;-)
>
>
>
>
>
> SR-MPLS:  https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1
>
> “determining the second label is impossible unless A1 and A2 allocated the 
> same label value to the same prefix.”
>
> “Using an anycast segment without configuring identical SRGBs on all
>
>nodes belonging to the same anycast group may lead to misrouting (in
>
>an MPLS VPN

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

2024-03-21 Thread Tony Przygienda

I can only say, `spot on, Bruno` ...

a spec in IGP is not (not even experimental AFAIS) "hey, let's quickly call
something 'anycast' and put a flag into encoding and then kind of figure
out what it really means", especially for such a massive concept as
"anycast" that will be coming up over years over and over again. So if its
semantics are not clear both in case of  SR and current behavior and any
new technology that may use it for  computations yielding different
semantics/behavior we will pay high technical debt for it in the future
(also called as mess where e'thing is called "anycast" but means different
things). If this here is "SR-anycast" only, fine, let's call the flag that
and define behavior of SR with it and then we may have then
"funny-routing-v8-anycast"-flag that behaves differently (which is to say
has hence different semantics). If this is really "THE anycast flag" then
it needs to define precise semantics as interacting with today's no
signalling "kind of anycast" and rely on and expectation what behavior for
_any_ future technology in IGP should yield as semantics for this flag.

-- tony

On Thu, Mar 21, 2024 at 11:42 AM  wrote:

> Hi all,
>
>
>
> I would also welcome a clear specification of the semantics.
>
> Such that the meaning and implications are clear on both the originator
> and the receivers/consumers.
>
>
>
> e.g., from the originator standpoint:
>
> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
> (which allow for some useful features such as….)
>
> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
> (otherwise this breaks …)
>
>
>
> Please specify the CONDITIONS1.
>
>
>
> e.g., from the receiver standpoint:
>
> What does this mean to have this Anycast Flag set? What properties are
> being signaled? (a priori this may be already specified by CONDITIONS1
> above)
>
>
>
>
>
> If this is specific to SR,  please say so. But even in this sub-case, SR
> anycast has some conditions, both for SR-MPLS and SRv6.
>
>
>
> SR-MPLS:  https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1
>
> “determining the second label is impossible unless A1 and A2 allocated the 
> same label value to the same prefix.”
>
> “Using an anycast segment without configuring identical SRGBs on all
>
>nodes belonging to the same anycast group may lead to misrouting (in
>
>an MPLS VPN deployment, some traffic may leak between VPNs).”
>
>
>
> So for SR-MPLS, where we did not have anycast flag at the time, the burden
> of respecting the conditions seems to be on the receiver. In which case,
> Anycast flag didn’t seem to be required.
>
>
>
> SRv6:
> https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert
>
> “All the nodes advertising the same anycast locator MUST instantiate the
> exact same set of SIDs under that anycast locator. Failure to do so may
> result in traffic being dropped or misrouted.”
>
>
>
> So for SRv6 the burden is on the originator, and we felt the need to
> define an anycast flag.
>
>
>
>
>
> Interestingly, the conditions seem different…
>
> Authors seems to use RFC9352 and RFC9513 as a justification. I’m not
> familiar with OSPFv2 but my understanding is that it does not advertise
> SRv6 SID. So presumably there are some differences
>
>
>
>
>
> “The prefix may be configured as anycast”
>
> Putting the burden on the network operator is not helping clarifying the
> semantic. We need the receivers/consumers and the network operators to have
> the same understanding of the semantic. (not to mention all implementations
> on the receiver side)
>
>
>
>
>
> So please specify the semantic.
>
> This may eventually lead to further discussion (e.g., on SR-MPLS)
>
>
>
> Thank you
>
> --Bruno
>
>
>
> *From:* Lsr  *On Behalf Of *Tony Przygienda
> *Sent:* Wednesday, March 20, 2024 5:44 PM
> *To:* Acee Lindem 
> *Cc:* Ketan Talaulikar ; Dongjie (Jimmy) <
> jie.d...@huawei.com>; lsr ;
> draft-chen-lsr-anycast-f...@ietf.org
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
>
> I think the draft is somewhat superfluous and worse, can generate
> completely unclear semantics
>
>
>
> 1) First, seeing the justification I doubt we need that flag. if the only
> need is for the SR controller to know it's anycast since it computes some
> paths this can be done by configuring the prefix on the controller itself.
> It's all centralized anyway.
>
> 2) OSPF today due to SPF limitations has a "baked-in weird anycast" since
> if prefixes are ECMP (from pont of view of a source) they become anycast,
> otherwise they ain't. I think the anycast SID suffers from same limi8ation
> and is hence not a "real anycast" (if _real anycast_ means something that
> independent of metrics balances on the prefix). Hence this draft saying
> "it's anycast" has completely unclear semantics to me, worse, possibly
> broken ones. What do I do as a router when this flag

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

2024-03-21 Thread bruno . decraene

Hi Ketan,

Thanks for your quick reply.
Please see inline [Bruno]

From: Ketan Talaulikar 
Sent: Thursday, March 21, 2024 2:18 PM
To: DECRAENE Bruno INNOV/NET 
Cc: Acee Lindem ; lsr ; 
draft-chen-lsr-anycast-f...@ietf.org; Dongjie (Jimmy) ; 
Tony Przygienda 
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Bruno,

Thanks for your feedback. Please check inline below for responses.

On Thu, Mar 21, 2024 at 4:12 PM 
mailto:bruno.decra...@orange.com>> wrote:
Hi all,

I would also welcome a clear specification of the semantics.
Such that the meaning and implications are clear on both the originator and the 
receivers/consumers.

e.g., from the originator standpoint:
- The originator MAY advertise the Anycast Flag if CONDITIONS1 are met (which 
allow for some useful features such as….)
- The originator MUST advertise the Anycast Flag if CONDITIONS1 are met 
(otherwise this breaks …)

Please specify the CONDITIONS1.

KT> Whether a prefix is anycast or not is configured by the operator. This spec 
does not require implementations to detect that a prefix that it is originating 
is also being originated from another node and hence may be an anycast 
advertisement. We can clarify the same in the document.

[Bruno] As an operator, why would I configure this? What for? What are the 
possible drawbacks? (i.e., can this be configured on all prefixes regardless of 
their anycast status)
I would propose those points be discussed in the operation considerations 
section of this draft.
In the absence of reason, this is not likely be configured IMHO.

e.g., from the receiver standpoint:
What does this mean to have this Anycast Flag set? What properties are being 
signaled? (a priori this may be already specified by CONDITIONS1 above)

KT> In addition to the previous response, for the receiver this means that the 
same prefix MAY be advertised from more than one node (that may be happening 
now or may happen in the future). This can be clarified as well.

[Bruno] OK. If this is happening now, this is a priori already visible in the 
LSDB. Any reason to duplicate the info (I would guess that’s easier for 
implementation but since this is not guaranteed to be implemented one would 
need to also check in the LSDB. So doubling the work).
Any specific reason requiring the knowledge of the future?

If this is specific to SR,  please say so.

KT> It is not specific to SR, it is a property of an IP prefix.

But even in this sub-case, SR anycast has some conditions, both for SR-MPLS and 
SRv6.

KT> This document does not discuss either SR-MPLS or SRv6 anycast. It covers an 
OSPFv2 extension to simply advertise the anycast property of any IP prefix. The 
discussion of SR anycast belongs to some other (SPRING) document ;-)

SR-MPLS:  https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1

“determining the second label is impossible unless A1 and A2 allocated the same 
label value to the same prefix.”

“Using an anycast segment without configuring identical SRGBs on all
   nodes belonging to the same anycast group may lead to misrouting (in
   an MPLS VPN deployment, some traffic may leak between VPNs).”

So for SR-MPLS, where we did not have anycast flag at the time, the burden of 
respecting the conditions seems to be on the receiver. In which case, Anycast 
flag didn’t seem to be required.

KT> True. But that was also beyond the anycast property of the prefix - it also 
involves checking the Prefix SID associated with it (plus other considerations) 
and that is something quite different.

SRv6: 
https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert
“All the nodes advertising the same anycast locator MUST instantiate the exact 
same set of SIDs under that anycast locator. Failure to do so may result in 
traffic being dropped or misrouted.”

So for SRv6 the burden is on the originator, and we felt the need to define an 
anycast flag.

KT> Note that RFC9352 does not restrict the advertisement of anycast property 
of the prefix to SRv6. It applies to all IPv4/IPv6 prefixes - irrespective of 
SRv6, SR-MPLSv4, SR-MPLSv6 or plain old IP. This is the same for RFC9513 - 
since OSPFv3 supports IPv4/IPv6 prefixes as well as SRv6, SR-MPLSv4, and 
SR-MPLSv6.
[Bruno] Indeed. And note that  RFC9352 did specify some specific conditions 
(MUST) before a node may advertise this anycast flag. A priori there is a 
reason for this. A priori the same reason would apply to SR-MPLS, no? So why 
this sentence has not also been copied from RFC9352 and adapted for SR-MPLS? 
(the sentence is “All the nodes advertising the same anycast locator MUST 
instantiate the exact same set of SIDs under that anycast locator. Failure to 
do so may result in traffic being dropped or misrouted.”)

Interestingly, the conditions seem different…
Authors seems to use RFC9352 and RFC9513 as a justification. I’m not familiar 
with OSPFv2 but my

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

Hi Bruno,

Thanks for your feedback. Please check inline below for responses.

On Thu, Mar 21, 2024 at 4:12 PM  wrote:

> Hi all,
>
>
>
> I would also welcome a clear specification of the semantics.
>
> Such that the meaning and implications are clear on both the originator
> and the receivers/consumers.
>
>
>
> e.g., from the originator standpoint:
>
> - The originator MAY advertise the Anycast Flag if CONDITIONS1 are met
> (which allow for some useful features such as….)
>
> - The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
> (otherwise this breaks …)
>
>
>
> Please specify the CONDITIONS1.
>

KT> Whether a prefix is anycast or not is configured by the operator. This
spec does not require implementations to detect that a prefix that it is
originating is also being originated from another node and hence may be an
anycast advertisement. We can clarify the same in the document.

>
>
> e.g., from the receiver standpoint:
>
> What does this mean to have this Anycast Flag set? What properties are
> being signaled? (a priori this may be already specified by CONDITIONS1
> above)
>

KT> In addition to the previous response, for the receiver this means that
the same prefix MAY be advertised from more than one node (that may be
happening now or may happen in the future). This can be clarified as well.

>
>
>
>
> If this is specific to SR,  please say so.
>

KT> It is not specific to SR, it is a property of an IP prefix.

> But even in this sub-case, SR anycast has some conditions, both for
> SR-MPLS and SRv6.
>

KT> This document does not discuss either SR-MPLS or SRv6 anycast. It
covers an OSPFv2 extension to simply advertise the anycast property of any
IP prefix. The discussion of SR anycast belongs to some other (SPRING)
document ;-)

>
>
> SR-MPLS:  https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1
>
> “determining the second label is impossible unless A1 and A2 allocated the 
> same label value to the same prefix.”
>
> “Using an anycast segment without configuring identical SRGBs on all
>
>nodes belonging to the same anycast group may lead to misrouting (in
>
>an MPLS VPN deployment, some traffic may leak between VPNs).”
>
>
>
> So for SR-MPLS, where we did not have anycast flag at the time, the burden
> of respecting the conditions seems to be on the receiver. In which case,
> Anycast flag didn’t seem to be required.
>

KT> True. But that was also beyond the anycast property of the prefix - it
also involves checking the Prefix SID associated with it (plus other
considerations) and that is something quite different.

>
>
> SRv6:
> https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert
>
> “All the nodes advertising the same anycast locator MUST instantiate the
> exact same set of SIDs under that anycast locator. Failure to do so may
> result in traffic being dropped or misrouted.”
>
>
>
> So for SRv6 the burden is on the originator, and we felt the need to
> define an anycast flag.
>

KT> Note that RFC9352 does not restrict the advertisement of anycast
property of the prefix to SRv6. It applies to all IPv4/IPv6 prefixes -
irrespective of SRv6, SR-MPLSv4, SR-MPLSv6 or plain old IP. This is the
same for RFC9513 - since OSPFv3 supports IPv4/IPv6 prefixes as well as
SRv6, SR-MPLSv4, and SR-MPLSv6.

>
>
>
>
> Interestingly, the conditions seem different…
>
> Authors seems to use RFC9352 and RFC9513 as a justification. I’m not
> familiar with OSPFv2 but my understanding is that it does not advertise
> SRv6 SID. So presumably there are some differences
>

KT> I hope the previous responses clarify.

>
>
>
>
> “The prefix may be configured as anycast”
>
> Putting the burden on the network operator is not helping clarifying the
> semantic. We need the receivers/consumers and the network operators to have
> the same understanding of the semantic. (not to mention all implementations
> on the receiver side)
>

KT> I hope again the previous responses have clarified.

>
>
>
>
> So please specify the semantic.
>
> This may eventually lead to further discussion (e.g., on SR-MPLS)
>

KT> That discussion is important and we've had offline conversations about
that. However, IMHO, that is beyond the scope of this document and this
thread.

Thanks,
Ketan

>
>
> Thank you
>
> --Bruno
>
>
>
> *From:* Lsr  *On Behalf Of *Tony Przygienda
> *Sent:* Wednesday, March 20, 2024 5:44 PM
> *To:* Acee Lindem 
> *Cc:* Ketan Talaulikar ; Dongjie (Jimmy) <
> jie.d...@huawei.com>; lsr ;
> draft-chen-lsr-anycast-f...@ietf.org
> *Subject:* Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast
> Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
>
>
>
> I think the draft is somewhat superfluous and worse, can generate
> completely unclear semantics
>
>
>
> 1) First, seeing the justification I doubt we need that flag. if the only
> need is for the SR controller to know it's anycast since it computes some
> paths this can be done by configuring the

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

2024-03-21 Thread bruno . decraene

Hi all,

I would also welcome a clear specification of the semantics.
Such that the meaning and implications are clear on both the originator and the 
receivers/consumers.

e.g., from the originator standpoint:
- The originator MAY advertise the Anycast Flag if CONDITIONS1 are met (which 
allow for some useful features such as….)
- The originator MUST advertise the Anycast Flag if CONDITIONS1 are met 
(otherwise this breaks …)

Please specify the CONDITIONS1.

e.g., from the receiver standpoint:
What does this mean to have this Anycast Flag set? What properties are being 
signaled? (a priori this may be already specified by CONDITIONS1 above)


If this is specific to SR,  please say so. But even in this sub-case, SR 
anycast has some conditions, both for SR-MPLS and SRv6.



SR-MPLS:  https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1

“determining the second label is impossible unless A1 and A2 allocated the same 
label value to the same prefix.”

“Using an anycast segment without configuring identical SRGBs on all
   nodes belonging to the same anycast group may lead to misrouting (in
   an MPLS VPN deployment, some traffic may leak between VPNs).”

So for SR-MPLS, where we did not have anycast flag at the time, the burden of 
respecting the conditions seems to be on the receiver. In which case, Anycast 
flag didn’t seem to be required.

SRv6: 
https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert
“All the nodes advertising the same anycast locator MUST instantiate the exact 
same set of SIDs under that anycast locator. Failure to do so may result in 
traffic being dropped or misrouted.”


So for SRv6 the burden is on the originator, and we felt the need to define an 
anycast flag.


Interestingly, the conditions seem different…
Authors seems to use RFC9352 and RFC9513 as a justification. I’m not familiar 
with OSPFv2 but my understanding is that it does not advertise SRv6 SID. So 
presumably there are some differences



“The prefix may be configured as anycast”
Putting the burden on the network operator is not helping clarifying the 
semantic. We need the receivers/consumers and the network operators to have the 
same understanding of the semantic. (not to mention all implementations on the 
receiver side)


So please specify the semantic.
This may eventually lead to further discussion (e.g., on SR-MPLS)

Thank you
--Bruno

From: Lsr  On Behalf Of Tony Przygienda
Sent: Wednesday, March 20, 2024 5:44 PM
To: Acee Lindem 
Cc: Ketan Talaulikar ; Dongjie (Jimmy) 
; lsr ; draft-chen-lsr-anycast-f...@ietf.org
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property 
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

I think the draft is somewhat superfluous and worse, can generate completely 
unclear semantics

1) First, seeing the justification I doubt we need that flag. if the only need 
is for the SR controller to know it's anycast since it computes some paths this 
can be done by configuring the prefix on the controller itself. It's all 
centralized anyway.
2) OSPF today due to SPF limitations has a "baked-in weird anycast" since if 
prefixes are ECMP (from pont of view of a source) they become anycast, 
otherwise they ain't. I think the anycast SID suffers from same limi8ation and 
is hence not a "real anycast" (if _real anycast_ means something that 
independent of metrics balances on the prefix). Hence this draft saying "it's 
anycast" has completely unclear semantics to me, worse, possibly broken ones. 
What do I do as a router when this flag is not around but two instances of the 
prefix are ECMP to me? What do I do on another router when those two instances 
have anycast but they are not ECMP? What will happen if the ECMP is lost due to 
ABR re-advertising where the "flag must be preserved" .
3) There is one good use case from my experience and this is to differentiate 
between a prefix moving between routers (mobility) and real anycast. That needs 
however far more stuff in terms of timestamping the prefix. pascal wrote and 
added that very carefully to rift if there is desire here to add proper anycast 
semantics support to the protocol.

So I'm not in favor in adopting this unless the semantic is clearly written out 
for this flag and the according procedures specified (mobility? behavior on 
lack/presence of flag of normal routers etc). Saying "

It

   is useful for other routers to know that the advertisement is for an

   anycast identifier.

" is not a use case or justification for adding this.

if this is "anycast in case of SR computed paths that are not ECMP" then the 
draft needs to say so and call it "SR anycast" or some such stuff. If it is 
something else I'd like to understand the semantics of this flag before this is 
adopted.

-- tony




On Wed, Mar 20, 2024 at 5:10 PM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Hi Ketan,


On Mar 20, 2024, at 12:07, Ketan Talaulikar 
mailto:ketant.i...@gmail.com>> wrote:

Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt

2024-03-21 Thread peng.shaofu

Hi Chairs, WG,

I have relearned this document, and there are some non-blocking comments:

[1]
For Interface Group Mode of automatic metric calculation, it may biases the 
utilization rate of each link of the parallel link-set. 
Although the document give an example (figure 7) to explain why this mode is 
applied, it seems not convincing. 
In Figure 7, the expected path is B-C-F-D, while B-E-D is an unexpected path. 
However please consider the following example that I believe that the expected 
path in this example should also be B-C-F-D + B-C'-F'-D (i.e., an ECMP path) if 
according to the same intention of the operators, but in this case most people 
may not consider them (i.e., the ECMP paths) as expected paths. There seems 
contradictory.
example:
A --- B  C  F  D
 C'  F' ---
- E 

[2]
For the description of Bandwidth Thresholds Sub-TLV of ISIS and OSPF, there are 
such descripton:
  "When the computed link bandwidth ... "
can it change to "when the used link bandwidth ..." ? 
IMO we can say the computed bandwidth metric but can not say the computed link 
bandwidth.

Please also check the erros of threshold #number as below:
When the computed link bandwidth is greater than or equal to Bandwidth 
Threshold 1 and less than Bandwidth Threshold 1(//should be threshold 2), 
Threshold Metric 1 MUST be assigned as the Bandwidth Metric on the link during 
the Flex-Algorithm SPF calculation.  
Similarly, when the computed link bandwidth is greater than or equal to 
Bandwidth Threshold 1 (//should be threshold 2) and less than Bandwidth 
Threshold 2(//should be threshold 3), Threshold Metric 2 MUST be assigned as 
the Bandwidth Metric on the link during the Flex-Algorithm SPF calculation.

[3]
For section 5. Bandwidth metric considerations, there may have errors:

4.In ISIS the Link Bandwidth for Flex-Algorithm purposes is advertised as a 
sub-sub-TLV 9 of the Flex-algorithm specific ASLA sub-TLV. It is also possible 
to advertise the link bandwidth or Flex-Algorith(// should be changed to "for 
Flex-Algorithm" ?), in sub-TLV 9 of TLV 22/222/23/223/141 [RFC5305], together 
with the L-Flag set in the Flex-Algorithm specific ASLA advertisement. In the 
absence of both of these advertisements, the bandwidth of the link is not 
available for Flex-Algorithm purposes.

Regards,
PSF

Original

From: AceeLindem 
To: lsr ;
Date: 2024年03月20日 11:00
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-flex-algo-bw-con-08.txt

Speaking as WG Member:

My comments have been addressed with this version and I support publication (as 
working member).  

Speaking as WG Co-Chair:  

It would be good for others  to review this draft as well  (and especially 
those writing Flex-Algo
extension drafts).  We had limited support (5 non-authors including myself). 
I'll give it another
week or so for review prior to requesting publication.  

Thanks,
Acee

> On Mar 18, 2024, at 6:56 AM, internet-dra...@ietf.org wrote:
>  
> Internet-Draft draft-ietf-lsr-flex-algo-bw-con-08.txt is now available. It is
> a work item of the Link State Routing (LSR) WG of the IETF.
>  
>   Title:   Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
>   Authors: Shraddha Hegde
>William Britto A J
>Rajesh Shetty
>Bruno Decraene
>Peter Psenak
>Tony Li
>   Name:draft-ietf-lsr-flex-algo-bw-con-08.txt
>   Pages:   30
>   Dates:   2024-03-18
>  
> Abstract:
>  
>   Many networks configure the link metric relative to the link
>   capacity.  High bandwidth traffic gets routed as per the link
>   capacity.  Flexible algorithms provide mechanisms to create
>   constraint based paths in IGP.  This draft documents a generic metric
>   type and set of bandwidth related constraints to be used in Flexible
>   Algorithms.
>  
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/
>  
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-08
>  
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flex-algo-bw-con-08
>  
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>  
>  
> ___
> 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___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07


Hi Jie,

On 21/03/2024 02:34, Dongjie (Jimmy) wrote:


Hi Les,

Thanks for providing your opinion with an example.

In your example, the default IGP metric is used, which is normally 
calculated based on bandwidth. While Flex-Algo can support metric 
types such as TE metric and delay.


When Flex-Algo is used as the control plane of NRP, usually the metric 
types other than IGP metric would be used. We could add some notes 
about the selection of metric type to this document. In most cases per 
Flex-Algo metric type would not be needed.


Your proposal of making each member link an L3 link is an alternative 
solution, while that would bring back the problems we discussed during 
the L2 bundle standardization, and can impact the network stability 
and scalability.


Your second proposal (controller based path computation and 
construction) works for scenarios where strict TE-path SID-list is 
used to steer traffic into specific bundle member links on each hop, 
while traffic with Flex-Algo prefix SIDs will be mixed up and ECMP 
among the member links of the L3 interface.


So we do see there is a gap in using Flex-Algo to support NRP, and 
would like to hear feedbacks from the WG on possible solutions 
(including this one).


there is no gap in Flex-algo. Flex-algo is a routing concept and as such 
only works on L3 constructs. That will not change.


The problem is that you are trying to mix the routing (flex-algo) with 
the PHB/QOS. These are two different things.


You can achieve PHP/QOS by marking the packet and give it a necessary 
treatment you need at each hop, e.g. reserve certain bandwidth to it, or 
even reserve a L2 bundle for it if that's what you want.


Alternatively, you can classify the traffic at each hop using other 
mechanisms, but it becomes slow and problematic.


What you propose is to overwrite the routing decision and instead of 
using the L3 outgoing interface computed based on L3 information, you 
install the specific L2 bundle member out of such L3 interface in 
forwatding. It works, because by using the L2 member of the L3 interface 
the traffic is forwarded to the same next-hop as has been calculated by 
the L3 routing. Nobody can stop you doing that locally if you wish doing 
so. But there is absolutely nothing you need from the IETF to do this. 
There is no need to advertise anything to do what you describe, as this 
is all a local behavior of the node. There is no need to add a new 
E-bit, and there is not even a need to advertise affinities for the L2 
bundle members.


I see no need for this draft.

thanks,
Peter




Best regards,

Jie

*From:*Les Ginsberg (ginsberg) 
*Sent:* Thursday, March 21, 2024 10:36 AM
*To:* Dongjie (Jimmy) ; lsr@ietf.org; 
draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org

*Subject:* RE: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

Jie -

Thanx for the quick response and confirming that my understanding of 
the intent of the draft is correct.


Making a routing decision when the full topology information is not 
provided as input to the Decision Process leads to incorrect or 
sub-optimal routing. Here is one simple example.


Consider the following simple topology (Layer 3 links):

  B

  /   \

A D

 \ /

C

All layer 3 links participate in Flex Algo 128.

On both B and C, the Layer 3 link to D is an L2 bundle and the total 
bandwidth of the bundle links are the same.


On link B-D, the L2 bundle member assigned to the NRP associated with 
flex algo 128 has 100 Mb of bandwidth.


On link C-D, the L2 bundle member assigned to the NRP associated with 
flex algo 128 has 1 GB of bandwidth.


The L3 SPF associated with algo 128 utilizes Layer 3 metric 
advertisements. Based on that, traffic from A to D will be equally 
balanced via B and C.


However, what you intend is that when algo 128 traffic is forwarded by 
B it will utilize a 100 Mb link – whereas when algo 128 traffic is 
forwarded by C it will utilize a 1 Gb link.


Clearly the ECMP traffic flow which is the output of the L3 SPF is 
sub-optimal.


How could this be fixed?

1)Do not use L2 bundles on B and C. Make each bundle member an L3 link 
and run IS-IS on the Layer 3 interfaces. In such a case different L3 
metrics can be advertised for each L3 link and Flex Algo 128 can be 
associated only with the desired L3 link on C and D.


Standard flex-algo as defined in RFC 9350 works and requires no 
modifications.


2)Do not use L3 routing/flex algo. Define some other mechanism to mark 
packets in a way that the forwarding recognizes as mapping to the 
appropriate L2 link.


The L2 bundle advertisements provided by IS-IS as per RFC 8668 can be 
used by this (external to IS-IS) mechanism.


For example this mechanism could use the admin group advertised for 
each L2Bundle member to determine the mapping between an NRP and a link.


All of the functionality required is already defined in RFC 8668 – the 
only thing you need to define is this new mechanism – which is not 
part of IS-IS and

Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06