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

[Les Ginsberg (ginsberg)]

Jie –

Inline.

From: Dongjie (Jimmy) 
Sent: Wednesday, March 20, 2024 6:35 PM
To: Les Ginsberg (ginsberg) ; 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

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.
[LES:] As I have stated, the number of metric-types is much less than the 
possible number of algorithms. Please do not define a solution which requires a 
different metric-type for each supported algorithm.

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.
[LES:] Addressing scale by hiding the topology from the entity which is 
required to do the correct NRP mapping (which is what you are doing in this 
draft) is not a good solution.
You need a solution which both scales and is still correct – not a compromise 
between the two.

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

[LES:] As I am sure you remember, we (including others) have discussed this 
offline and you know that I believe the routing protocols are NOT a good fit 
for what has historically been addressed using QOS mechanisms.
And TEAS drafts on which you are co-author make statements which discourage the 
use of routing protocols. For example see 
https://www.ietf.org/archive/id/draft-ietf-teas-nrp-scalability-04.html#name-scalability-design-principl

“The routing protocols (IGP or BGP) does not have to be involved in any of 
these points, but when they need to, it is important to isolate information of 
network slices and NRPs from existing routing information, so that there is no 
impact on scaling or stability. Furthermore, the complexity of SPF computation 
should not be impacted by the increasing number of network slices and NRPs.”

This suggests that if you were to use routing protocols at all, you do not 
recommend doing so at scale, which means your remark above concerning scale and 
not using L2 bundles seems misplaced. It seems even you are not expecting to 
use routing protocol in support of NRP at scale.

No doubt much more discussion required – both in TEAS and LSR – but I do feel 
strongly that this draft should not go forward.

   Les


Best regards,
Jie

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Thursday, March 21, 2024 10:36 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; 
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 

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

[Dongjie (Jimmy)]

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

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 
therefore does not belong in an LSR draft.



NOTE: Please do not suggest that a different metric-type can be used for each 
Flex-Algo. Such an approach does not scale as it requires as many metric-types 
as Flex-Algos – which we do not have. 



What you MUST NOT do is use L3 routing to make a routing decision for a 
topology which is not part of the input to the routing decision process. But 
that is exactly what you are proposing in this draft.



Hope this example is clear.



As regards the clarity of Section 4, that section simply says (using the 
SR-MPLS text):



“A forwarding entry MUST be installed in the forwarding plane using the MPLS 
label that corresponds to the Prefix-SID associated with the Flex-algorithm 
corresponding to the NRP.”



But this entry must have next hops which include only the L2 links associated 
with the NRP mapped to Flex-algo 128. How this is done is not described – but 
as it requires using information advertised in the L2 Bundle Member Descriptors 
this clearly cannot be done by IS-IS w/o violating RFC 8668. IS-IS will simply 
attempt to install a forwarding entry based on the L3 topology – which will 
indicate to use the L3 link. How this forwarding entry is discarded/overwritten 
is not specified. But, this is a problem which should never need to be solved.



   Les







> -Original Message-

> From: Dongjie (Jimmy) 

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

[Les Ginsberg (ginsberg)]

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 
therefore does not belong in an LSR draft.



NOTE: Please do not suggest that a different metric-type can be used for each 
Flex-Algo. Such an approach does not scale as it requires as many metric-types 
as Flex-Algos – which we do not have. 



What you MUST NOT do is use L3 routing to make a routing decision for a 
topology which is not part of the input to the routing decision process. But 
that is exactly what you are proposing in this draft.



Hope this example is clear.



As regards the clarity of Section 4, that section simply says (using the 
SR-MPLS text):



“A forwarding entry MUST be installed in the forwarding plane using the MPLS 
label that corresponds to the Prefix-SID associated with the Flex-algorithm 
corresponding to the NRP.”



But this entry must have next hops which include only the L2 links associated 
with the NRP mapped to Flex-algo 128. How this is done is not described – but 
as it requires using information advertised in the L2 Bundle Member Descriptors 
this clearly cannot be done by IS-IS w/o violating RFC 8668. IS-IS will simply 
attempt to install a forwarding entry based on the L3 topology – which will 
indicate to use the L3 link. How this forwarding entry is discarded/overwritten 
is not specified. But, this is a problem which should never need to be solved.



   Les







> -Original Message-

> From: Dongjie (Jimmy) 

> Sent: Wednesday, March 20, 2024 4:30 PM

> To: Les Ginsberg (ginsberg) ; 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

>

> Hi Les,

>

> Thanks for the review and comments.

>

> Please see some replies inline:

>

> > -Original Message-

> > From: Les Ginsberg (ginsberg) 
> > mailto:ginsb...@cisco.com>>

> > Sent: Thursday, March 21, 2024 7:32 AM

> > To: lsr@ietf.org; 
> > draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org

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

> >

> > This draft discusses how to use flex-algo in support of Network Resource

> > Partitions (NRPs). In particular, it proposes to use a combination of L3 
> > links

> and

> > L2 Bundle member links as the topology associated with a given NRP. In

> those

> > cases where an L3 link is using an L2 bundle and individual bundle members

> > are "assigned" to different NRPs, it then proposes to associate the parent 
> > L3

> > link with multiple flex-algos. The intent seems to be to utilize the L3 algo

> > specific SIDs to assign the traffic to subsets of the L2 Bundle members.

>

> Your reading of the intent of this document is correct.

>

> With the proposed mechanism, traffic with Flex-Algo specific SIDs could be

> steered to different 

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

[Ketan Talaulikar]

Sure Jie. We will add post adoption.

Thanks,
Ketan


On Thu, Mar 21, 2024 at 5:16 AM Dongjie (Jimmy)  wrote:

> Hi Ketan,
>
>
>
> Thanks for sharing the use cases of this new flag. It would be helpful if
> some brief description could be added to the document.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Ketan Talaulikar 
> *Sent:* Thursday, March 21, 2024 1:18 AM
> *To:* Acee Lindem 
> *Cc:* 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
>
>
>
> Hi Acee/Jie,
>
>
>
> The most common users of the anycast property of a prefix are external
> controllers/PCE that perform path computation exercises. As an example,
> knowing the anycast prefix of a pair of redundant ABRs allows that anycast
> prefix SID to be in a SRTE path across the ABRs with protection against one
> of those ABR nodes going down or getting disconnected. There are other use
> cases. An example of local use on the router by IGPs is to avoid picking
> anycast SIDs in the repair segment-list prepared for TI-LFA protection -
> this is because it could cause an undesirable path that may not be aligned
> during the FRR window and/or post-convergence.
>
>
>
> That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the
> burden of this justification of an use-case, I hope the same burden would
> not fall on this OSPFv2 document simply because it only has this one
> specific extension.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem  wrote:
>
> Hi Jie,
>
> I asked this when the flag was added to IS-IS and then to OSPFv3. I agree
> it would be good to know why knowing a prefix is an Anycast address is
> "useful" when the whole point is that you use the closest one (or some
> other criteria).
>
> Thanks,
> Acee
>
> > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) 
> wrote:
> >
> > Hi authors,
> >
> > I just read this document. Maybe I didn't follow the previous
> discussion, but it seems in the current version it does not describe how
> this newly defined flag would be used by the receiving IGP nodes?
> >
> > Best regards,
> > Jie
> >
> > -Original Message-
> > From: Lsr  On Behalf Of Acee Lindem
> > Sent: Wednesday, March 20, 2024 4: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

[Dongjie (Jimmy)]

Hi Ketan,

Thanks for sharing the use cases of this new flag. It would be helpful if some 
brief description could be added to the document.

Best regards,
Jie

From: Ketan Talaulikar 
Sent: Thursday, March 21, 2024 1:18 AM
To: Acee Lindem 
Cc: 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

Hi Acee/Jie,

The most common users of the anycast property of a prefix are external 
controllers/PCE that perform path computation exercises. As an example, knowing 
the anycast prefix of a pair of redundant ABRs allows that anycast prefix SID 
to be in a SRTE path across the ABRs with protection against one of those ABR 
nodes going down or getting disconnected. There are other use cases. An example 
of local use on the router by IGPs is to avoid picking anycast SIDs in the 
repair segment-list prepared for TI-LFA protection - this is because it could 
cause an undesirable path that may not be aligned during the FRR window and/or 
post-convergence.

That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the burden of 
this justification of an use-case, I hope the same burden would not fall on 
this OSPFv2 document simply because it only has this one specific extension.

Thanks,
Ketan


On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:
Hi Jie,

I asked this when the flag was added to IS-IS and then to OSPFv3. I agree it 
would be good to know why knowing a prefix is an Anycast address is "useful" 
when the whole point is that you use the closest one (or some other criteria).

Thanks,
Acee

> On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) 
> mailto:jie.d...@huawei.com>> wrote:
>
> Hi authors,
>
> I just read this document. Maybe I didn't follow the previous discussion, but 
> it seems in the current version it does not describe how this newly defined 
> flag would be used by the receiving IGP nodes?
>
> Best regards,
> Jie
>
> -Original Message-
> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Acee Lindem
> Sent: Wednesday, March 20, 2024 4:43 AM
> To: lsr mailto:lsr@ietf.org>>
> 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] Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07

[Dongjie (Jimmy)]

Hi Les,

Thanks for the review and comments. 

Please see some replies inline:

> -Original Message-
> From: Les Ginsberg (ginsberg) 
> Sent: Thursday, March 21, 2024 7:32 AM
> To: lsr@ietf.org; draft-zhu-lsr-isis-sr-vtn-flexalgo.auth...@ietf.org
> Subject: Comments on draft-zhu-lsr-isis-sr-vtn-flexalgo-07
> 
> This draft discusses how to use flex-algo in support of Network Resource
> Partitions (NRPs). In particular, it proposes to use a combination of L3 
> links and
> L2 Bundle member links as the topology associated with a given NRP. In those
> cases where an L3 link is using an L2 bundle and individual bundle members
> are "assigned" to different NRPs, it then proposes to associate the parent L3
> link with multiple flex-algos. The intent seems to be to utilize the L3 algo
> specific SIDs to assign the traffic to subsets of the L2 Bundle members.

Your reading of the intent of this document is correct. 

With the proposed mechanism, traffic with Flex-Algo specific SIDs could be 
steered to different partitions of the L3 link resources. 

The only thing I'd like to mention is the L2 bundle members could be virtual or 
physical, they are just used to represent different subsets of the link 
resources.


> This is extremely problematic.
> 
> The output of the L3 algo-specific SPF will be to install nexthops pointing 
> to the
> L3 interface for packets which arrive with the L3 algo specific SID. But 
> since the
> intent is to only forward traffic for a given algo specific SID via specific 
> L2
> Bundle members, the L3 forwarding entries will have to be overwritten - in a
> manner not specified by the draft.

Section 4 of this document specifies the required forwarding plane behavior and 
the forwarding entry installation.


> The implementation complexities this introduces arise because the proposed
> solution attempts to use a Layer 3 technology (flex-algo) to control the use 
> of
> L2 links. This should not be done.

In the proposed mechanism, Flex-Algo is still used for constraint path 
computation, and only the L3 links attributes are used in the computation. The 
L2 member links are only to partition the resources used by different Flex-Algo 
traffic. 


> Indeed, even independent of flex-algo, trying to use a Layer 3 routing 
> protocol
> to control traffic flow on an L2 sub-topology is broken.
> It means that the L2 bundles have been improperly defined for use by the L3
> routing protocol.

There is no routing computation based on the "L2 sub-topology", as L2 bundle 
member links are not visible in the L3DB. All the Flex-Algo computation is 
based on the attributes of L3 links.


> RFC 8668 defines the advertisements of L2 Bundle member link attributes by
> IS-IS. The introduction of RFC 8668 states:
> 
> "...the new advertisements defined in this document are intended to be
> provided to external (to IS-IS) entities."
> 
> This means these advertisements are not to be used by the routing protocol
> itself. The association of these advertisements with the Layer 3 SIDs defined 
> by
> Flex-Algo is a clear violation of the intended use as stated by RFC 8668.

As stated above, L2 bundle link attributes are not used in path computation. 
The Flex-Algo specific SIDs still point to the L3 interface based on that 
computation. The only change is that a Flex-Algo SID can further points to the 
resource of an L2 member link (consider it as a subset of the resource of the 
L3 link if that is easier to understand). So the L2 bundle information is only 
used for associating different Flex-Algo SIDs with different subsets of 
resources of a l3 link.  


> This draft should be abandoned.
> 
> NOTE: None of the points above should be interpreted to mean that flex-algo
> cannot be used in support of NRPs. (Whether that is a good idea or not is out
> of scope for this discussion).

AFAIK people are talking about using Flex-Algo to support NRPs. This document 
provides a solution to meet their needs. 


> But the proper way to do that is when the NRP maps to an L3 topology. Such a
> usage is fully supported by RFC 9350 and there is no need to write an
> additional document to define how this is to be done.

In some cases it is possible to map different NRPs to non-overlapping L3 
sub-topologies, while in many other cases the same L3 link needs to participate 
in multiple NRPs, each of which is assigned with a subset of the link 
resources. The latter case cannot be supported by RFC 9350, and it is the 
target of this document. 


> In cases where an NRP maps to an L2 topology, some other mechanism needs
> to be defined as to how forwarding entries for a given NRP are determined and
> installed. Such a mechanism would qualify as "external to IS-IS" and therefore
> could make use of RFC 8668 advertisements.

This document also provides descriptions about this. As I mentioned it is after 
L3 computation, and makes use of the L2 bundle information. 


> But attempts to utilize the Layer 3 Flex-Algo 

[Lsr] Need volunteers to help with minutes

[Yingzhen Qu]

Hi,

We need a couple of volunteers to help with minutes:
HedgeDoc - Collaborative markdown notes (ietf.org)


Please let us know if you'd like to help.

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

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

[Les Ginsberg (ginsberg)]

This draft discusses how to use flex-algo in support of Network Resource 
Partitions (NRPs). In particular, it proposes to use a combination of L3 links 
and
L2 Bundle member links as the topology associated with a given NRP. In those 
cases where an L3 link is using an L2 bundle and individual bundle members
are "assigned" to different NRPs, it then proposes to associate the parent L3 
link with multiple flex-algos. The intent seems to be to utilize the L3
algo specific SIDs to assign the traffic to subsets of the L2 Bundle members.

This is extremely problematic.

The output of the L3 algo-specific SPF will be to install nexthops pointing to 
the L3 interface for packets which arrive with
the L3 algo specific SID. But since the intent is to only forward traffic for a 
given algo specific SID via specific L2 Bundle members, the L3
forwarding entries will have to be overwritten - in a manner not specified by 
the draft.

The implementation complexities this introduces arise because the proposed 
solution attempts to use a Layer 3 technology (flex-algo) to control the
use of L2 links. This should not be done.

Indeed, even independent of flex-algo, trying to use a Layer 3 routing protocol 
to control traffic flow on an L2 sub-topology is broken.
It means that the L2 bundles have been improperly defined for use by the L3 
routing protocol.

RFC 8668 defines the advertisements of L2 Bundle member link attributes by 
IS-IS. The introduction of RFC 8668 states:

"...the new advertisements defined in this document are intended to be provided 
to external (to IS-IS) entities."

This means these advertisements are not to be used by the routing protocol
itself. The association of these advertisements with the Layer 3 SIDs
defined by Flex-Algo is a clear violation of the intended use as stated by RFC
8668.

This draft should be abandoned.

NOTE: None of the points above should be interpreted to mean that flex-algo
cannot be used in support of NRPs. (Whether that is a good idea or not
is out of scope for this discussion).

But the proper way to do that is when the NRP maps to an L3 topology. Such
a usage is fully supported by RFC 9350 and there is no need to write an
additional document to define how this is to be done.

In cases where an NRP maps to an L2 topology, some other mechanism needs
to be defined as to how forwarding entries for a given NRP are determined
and installed. Such a mechanism would qualify as "external to IS-IS" and
therefore could make use of RFC 8668 advertisements.

But attempts to utilize the Layer 3 Flex-Algo technology to control traffic
flow in an L2 topology are misguided and flawed.

   Les

___
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

[Tony Przygienda]

hmm, Peter, thanks for clarification but wasn't A the attach flag is OSPF
in 7684?

In ISIS it's in the SR support draft and hence I would ask here as well to
somehow clarify that  "this is for SR purposes"  and call the draft
accordingly before we get it confused with today's semantics. And possibly
call the flag the "SR-anycast flag" or some such thing that clarifies it
does not have anything to do with "normal" OSPF pseudo-anycast

I buy your 2nd use case

I don't get the first, are we talking TI-LFA with SR only? because
otherwise it's a tunnel and hence doesn't matter whether it traversed an
anycast . So for me it looks like SR specific thing again.

thanks

-- tony

On Wed, Mar 20, 2024 at 6:22 PM Peter Psenak  wrote:

> Tony,
>
> there are two use cases:
>
> 1. Your application wants to exclude address that is anycast - an example
> of where this can be used internally by IGP is a TI-LFA or uloop, when
> picking up the address of the node over which we want to do the
> enforcement. There is a N bit as well, but in case there is no address with
> the N-bit, you want to exclude anycast addresses.
>
> 2. Your application want to use only anycast addresses - inter-domain SRTE
> with anycast address for ASBRs. SRTE is using the IGP topology provided by
> BGP-LS.
>
> BTW, the A-bit exists in ISIS and OSPFv3. We are just filling the gap with
> this draft.
>
> thanks,
> Peter
>
>
>
> On 20/03/2024 17:44, Tony Przygienda wrote:
>
> 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.
>
> please see the TI-LFA, uloop use case that is internal to IGP.
>
>
> 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  wrote:
>
>> Hi Ketan,
>>
>> On Mar 20, 2024, at 12:07, Ketan Talaulikar 
>> wrote:
>>
>> Sure, Acee. We can take that on :-)
>>
>> I hope it is ok that this is done post adoption?
>>
>>
>> Yup. I realize this is a simple draft to fill an IGP gap but I did ask
>> the question below. Hopefully, we can get to WG last call quickly.
>>
>> Thanks,
>> Acee
>>
>>
>>
>>
>> Thanks,
>> Ketan
>>
>>
>> On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem  wrote:
>>
>>>
>>>
>>> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar 
>>> wrote:
>>> >
>>> > Hi Acee/Jie,
>>> >
>>> > The most common users of the anycast property of a prefix are external
>>> controllers/PCE that perform path computation exercises. As an example,
>>> knowing the anycast prefix of a pair of redundant ABRs allows that anycast
>>> prefix SID to be in a SRTE path across the ABRs with protection against one
>>> of those ABR nodes going down or getting disconnected. There are other use
>>> cases. An example of local use on the router by IGPs is to avoid picking
>>> anycast SIDs in the repair segment-list prepared for TI-LFA protection -
>>> this is because it could cause an undesirable path that may not be aligned
>>> during the FRR window and/or post-convergence.
>>> >
>>> > That said, since ISIS (RFC9352) and OSPFv3 

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

[Peter Psenak]

Tony,

there are two use cases:

1. Your application wants to exclude address that is anycast - an 
example of where this can be used internally by IGP is a TI-LFA or 
uloop, when picking up the address of the node over which we want to do 
the enforcement. There is a N bit as well, but in case there is no 
address with the N-bit, you want to exclude anycast addresses.


2. Your application want to use only anycast addresses - inter-domain 
SRTE with anycast address for ASBRs. SRTE is using the IGP topology 
provided by BGP-LS.


BTW, the A-bit exists in ISIS and OSPFv3. We are just filling the gap 
with this draft.


thanks,
Peter



On 20/03/2024 17:44, Tony Przygienda wrote:
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.


please see the TI-LFA, uloop use case that is internal to IGP.


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

Hi Ketan,


On Mar 20, 2024, at 12:07, Ketan Talaulikar
 wrote:

Sure, Acee. We can take that on :-)

I hope it is ok that this is done post adoption?


Yup. I realize this is a simple draft to fill an IGP gap but I did
ask the question below. Hopefully, we can get to WG last call
quickly.

Thanks,
Acee





Thanks,
Ketan


On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem 
wrote:



> On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar
 wrote:
>
> Hi Acee/Jie,
>
> The most common users of the anycast property of a prefix
are external controllers/PCE that perform path computation
exercises. As an example, knowing the anycast prefix of a
pair of redundant ABRs allows that anycast prefix SID to be
in a SRTE path across the ABRs with protection against one of
those ABR nodes going down or getting disconnected. There are
other use cases. An example of local use on the router by
IGPs is to avoid picking anycast SIDs in the repair
segment-list prepared for TI-LFA protection - this is because
it could cause an undesirable path that may not be aligned
during the FRR window and/or post-convergence.
>
> That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't
have the burden of this justification of an use-case, I hope
the same burden would not fall on this OSPFv2 document simply
because it only has this one specific extension.

But they also weren't added in a draft specifically devoted
to the Anycast flag. It would be good to list the examples
above as  potential use cases.


Thanks,
Acee



>
> Thanks,
> Ketan
>
>
> On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem
 wrote:
> Hi Jie,
>
> I asked this when the flag was added to IS-IS and then to
OSPFv3. I agree it would be good to know why knowing a prefix
is an Anycast address 

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

[Tony Przygienda]

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

> Hi Ketan,
>
> On Mar 20, 2024, at 12:07, Ketan Talaulikar  wrote:
>
> Sure, Acee. We can take that on :-)
>
> I hope it is ok that this is done post adoption?
>
>
> Yup. I realize this is a simple draft to fill an IGP gap but I did ask the
> question below. Hopefully, we can get to WG last call quickly.
>
> Thanks,
> Acee
>
>
>
>
> Thanks,
> Ketan
>
>
> On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem  wrote:
>
>>
>>
>> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar 
>> wrote:
>> >
>> > Hi Acee/Jie,
>> >
>> > The most common users of the anycast property of a prefix are external
>> controllers/PCE that perform path computation exercises. As an example,
>> knowing the anycast prefix of a pair of redundant ABRs allows that anycast
>> prefix SID to be in a SRTE path across the ABRs with protection against one
>> of those ABR nodes going down or getting disconnected. There are other use
>> cases. An example of local use on the router by IGPs is to avoid picking
>> anycast SIDs in the repair segment-list prepared for TI-LFA protection -
>> this is because it could cause an undesirable path that may not be aligned
>> during the FRR window and/or post-convergence.
>> >
>> > That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the
>> burden of this justification of an use-case, I hope the same burden would
>> not fall on this OSPFv2 document simply because it only has this one
>> specific extension.
>>
>> But they also weren't added in a draft specifically devoted to the
>> Anycast flag. It would be good to list the examples above as  potential use
>> cases.
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>> >
>> > Thanks,
>> > Ketan
>> >
>> >
>> > On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem 
>> wrote:
>> > Hi Jie,
>> >
>> > I asked this when the flag was added to IS-IS and then to OSPFv3. I
>> agree it would be good to know why knowing a prefix is an Anycast address
>> is "useful" when the whole point is that you use the closest one (or some
>> other criteria).
>> >
>> > Thanks,
>> > Acee
>> >
>> > > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) 
>> wrote:
>> > >
>> > > Hi authors,
>> > >
>> > > I just read this document. Maybe I didn't follow the previous
>> discussion, but it seems in the current version it does not describe how
>> this newly defined flag would be used by the receiving IGP nodes?
>> > >
>> > > Best regards,
>> > > Jie
>> > >
>> > > -Original Message-
>> > > From: Lsr  On Behalf Of Acee Lindem
>> > > Sent: Wednesday, March 20, 2024 4: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 

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

[Acee Lindem]

Hi Ketan, 

> On Mar 20, 2024, at 12:07, Ketan Talaulikar  wrote:
> 
> Sure, Acee. We can take that on :-)
> 
> I hope it is ok that this is done post adoption?

Yup. I realize this is a simple draft to fill an IGP gap but I did ask the 
question below. Hopefully, we can get to WG last call quickly. 

Thanks,
Acee



> 
> Thanks,
> Ketan
> 
> 
> On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem  > wrote:
>> 
>> 
>> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar > > > wrote:
>> > 
>> > Hi Acee/Jie,
>> > 
>> > The most common users of the anycast property of a prefix are external 
>> > controllers/PCE that perform path computation exercises. As an example, 
>> > knowing the anycast prefix of a pair of redundant ABRs allows that anycast 
>> > prefix SID to be in a SRTE path across the ABRs with protection against 
>> > one of those ABR nodes going down or getting disconnected. There are other 
>> > use cases. An example of local use on the router by IGPs is to avoid 
>> > picking anycast SIDs in the repair segment-list prepared for TI-LFA 
>> > protection - this is because it could cause an undesirable path that may 
>> > not be aligned during the FRR window and/or post-convergence.
>> > 
>> > That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the 
>> > burden of this justification of an use-case, I hope the same burden would 
>> > not fall on this OSPFv2 document simply because it only has this one 
>> > specific extension.
>> 
>> But they also weren't added in a draft specifically devoted to the Anycast 
>> flag. It would be good to list the examples above as  potential use cases.
>> 
>> 
>> Thanks,
>> Acee
>> 
>> 
>> 
>> > 
>> > Thanks,
>> > Ketan
>> > 
>> > 
>> > On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem > > > wrote:
>> > Hi Jie,
>> > 
>> > I asked this when the flag was added to IS-IS and then to OSPFv3. I agree 
>> > it would be good to know why knowing a prefix is an Anycast address is 
>> > "useful" when the whole point is that you use the closest one (or some 
>> > other criteria). 
>> > 
>> > Thanks,
>> > Acee
>> > 
>> > > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) > > > > wrote:
>> > > 
>> > > Hi authors,
>> > > 
>> > > I just read this document. Maybe I didn't follow the previous 
>> > > discussion, but it seems in the current version it does not describe how 
>> > > this newly defined flag would be used by the receiving IGP nodes? 
>> > > 
>> > > Best regards,
>> > > Jie
>> > > 
>> > > -Original Message-
>> > > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf 
>> > > Of Acee Lindem
>> > > Sent: Wednesday, March 20, 2024 4:43 AM
>> > > To: lsr mailto:lsr@ietf.org>>
>> > > 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

[Ketan Talaulikar]

Sure, Acee. We can take that on :-)

I hope it is ok that this is done post adoption?

Thanks,
Ketan


On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem  wrote:

>
>
> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar 
> wrote:
> >
> > Hi Acee/Jie,
> >
> > The most common users of the anycast property of a prefix are external
> controllers/PCE that perform path computation exercises. As an example,
> knowing the anycast prefix of a pair of redundant ABRs allows that anycast
> prefix SID to be in a SRTE path across the ABRs with protection against one
> of those ABR nodes going down or getting disconnected. There are other use
> cases. An example of local use on the router by IGPs is to avoid picking
> anycast SIDs in the repair segment-list prepared for TI-LFA protection -
> this is because it could cause an undesirable path that may not be aligned
> during the FRR window and/or post-convergence.
> >
> > That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the
> burden of this justification of an use-case, I hope the same burden would
> not fall on this OSPFv2 document simply because it only has this one
> specific extension.
>
> But they also weren't added in a draft specifically devoted to the Anycast
> flag. It would be good to list the examples above as  potential use cases.
>
>
> Thanks,
> Acee
>
>
>
> >
> > Thanks,
> > Ketan
> >
> >
> > On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem  wrote:
> > Hi Jie,
> >
> > I asked this when the flag was added to IS-IS and then to OSPFv3. I
> agree it would be good to know why knowing a prefix is an Anycast address
> is "useful" when the whole point is that you use the closest one (or some
> other criteria).
> >
> > Thanks,
> > Acee
> >
> > > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) 
> wrote:
> > >
> > > Hi authors,
> > >
> > > I just read this document. Maybe I didn't follow the previous
> discussion, but it seems in the current version it does not describe how
> this newly defined flag would be used by the receiving IGP nodes?
> > >
> > > Best regards,
> > > Jie
> > >
> > > -Original Message-
> > > From: Lsr  On Behalf Of Acee Lindem
> > > Sent: Wednesday, March 20, 2024 4: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

[Acee Lindem]

> On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar  wrote:
> 
> Hi Acee/Jie,
> 
> The most common users of the anycast property of a prefix are external 
> controllers/PCE that perform path computation exercises. As an example, 
> knowing the anycast prefix of a pair of redundant ABRs allows that anycast 
> prefix SID to be in a SRTE path across the ABRs with protection against one 
> of those ABR nodes going down or getting disconnected. There are other use 
> cases. An example of local use on the router by IGPs is to avoid picking 
> anycast SIDs in the repair segment-list prepared for TI-LFA protection - this 
> is because it could cause an undesirable path that may not be aligned during 
> the FRR window and/or post-convergence.
> 
> That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the burden 
> of this justification of an use-case, I hope the same burden would not fall 
> on this OSPFv2 document simply because it only has this one specific 
> extension.

But they also weren't added in a draft specifically devoted to the Anycast 
flag. It would be good to list the examples above as  potential use cases.


Thanks,
Acee



> 
> Thanks,
> Ketan
> 
> 
> On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem  wrote:
> Hi Jie,
> 
> I asked this when the flag was added to IS-IS and then to OSPFv3. I agree it 
> would be good to know why knowing a prefix is an Anycast address is "useful" 
> when the whole point is that you use the closest one (or some other 
> criteria). 
> 
> Thanks,
> Acee
> 
> > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy)  wrote:
> > 
> > Hi authors,
> > 
> > I just read this document. Maybe I didn't follow the previous discussion, 
> > but it seems in the current version it does not describe how this newly 
> > defined flag would be used by the receiving IGP nodes? 
> > 
> > Best regards,
> > Jie
> > 
> > -Original Message-
> > From: Lsr  On Behalf Of Acee Lindem
> > Sent: Wednesday, March 20, 2024 4: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

[Ketan Talaulikar]

Hi Acee/Jie,

The most common users of the anycast property of a prefix are external
controllers/PCE that perform path computation exercises. As an example,
knowing the anycast prefix of a pair of redundant ABRs allows that anycast
prefix SID to be in a SRTE path across the ABRs with protection against one
of those ABR nodes going down or getting disconnected. There are other use
cases. An example of local use on the router by IGPs is to avoid picking
anycast SIDs in the repair segment-list prepared for TI-LFA protection -
this is because it could cause an undesirable path that may not be aligned
during the FRR window and/or post-convergence.

That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the burden
of this justification of an use-case, I hope the same burden would not fall
on this OSPFv2 document simply because it only has this one specific
extension.

Thanks,
Ketan


On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem  wrote:

> Hi Jie,
>
> I asked this when the flag was added to IS-IS and then to OSPFv3. I agree
> it would be good to know why knowing a prefix is an Anycast address is
> "useful" when the whole point is that you use the closest one (or some
> other criteria).
>
> Thanks,
> Acee
>
> > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) 
> wrote:
> >
> > Hi authors,
> >
> > I just read this document. Maybe I didn't follow the previous
> discussion, but it seems in the current version it does not describe how
> this newly defined flag would be used by the receiving IGP nodes?
> >
> > Best regards,
> > Jie
> >
> > -Original Message-
> > From: Lsr  On Behalf Of Acee Lindem
> > Sent: Wednesday, March 20, 2024 4: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

[Lsr] draft-ietf-lsr-isis-fast-flooding-08

[bruno . decraene]

Mirja, Barry, all

-08 is expected to address the comments from Mirja and Barry as discussed on 
the list. Plus one editorial comment from John.

Thank you for your comments.

To date, I believe that all comments have been addressed. So if I forgot 
one/your comment, please ping us again.


Thanks,
--Bruno, authors

-Original Message-
From: I-D-Announce  On Behalf Of 
internet-dra...@ietf.org
Sent: Wednesday, March 20, 2024 3:54 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: I-D Action: draft-ietf-lsr-isis-fast-flooding-08.txt

Internet-Draft draft-ietf-lsr-isis-fast-flooding-08.txt is now available. It is 
a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   IS-IS Fast Flooding
   Authors: Bruno Decraene
Les Ginsberg
Tony Li
Guillaume Solignac
Marek Karasek
Gunter Van de Velde
Tony Przygienda
   Name:draft-ietf-lsr-isis-fast-flooding-08.txt
   Pages:   27
   Dates:   2024-03-20

Abstract:

   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-08
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce


Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-08.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-isis-fast-flooding-08.txt is now available. It
is a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   IS-IS Fast Flooding
   Authors: Bruno Decraene
Les Ginsberg
Tony Li
Guillaume Solignac
Marek Karasek
Gunter Van de Velde
Tony Przygienda
   Name:draft-ietf-lsr-isis-fast-flooding-08.txt
   Pages:   27
   Dates:   2024-03-20

Abstract:

   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-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

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

[Acee Lindem]

Hi Jie,

I asked this when the flag was added to IS-IS and then to OSPFv3. I agree it 
would be good to know why knowing a prefix is an Anycast address is "useful" 
when the whole point is that you use the closest one (or some other criteria). 

Thanks,
Acee

> On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy)  wrote:
> 
> Hi authors,
> 
> I just read this document. Maybe I didn't follow the previous discussion, but 
> it seems in the current version it does not describe how this newly defined 
> flag would be used by the receiving IGP nodes? 
> 
> Best regards,
> Jie
> 
> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Wednesday, March 20, 2024 4: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] Secdir last call review of draft-ietf-lsr-isis-fast-flooding-07

[bruno . decraene]

Barry, Les 
 
> From: Barry Leiba  
> Sent: Saturday, March 16, 2024 1:05 AM
> 
> Indeed; given the explanation and the fact that it's copied from otherwise 
> existing text, I think Les is right: just leave it as is, and thanks for 
> considering and discussing my question.

Thanks for your comments and feedback.

I'm reverting to the original text:  Length: Indicates the length in octets 
(1-8) of the Value field. The length SHOULD be the minimum required to send all 
bits that are set.

Thanks
--Bruno
 
> Barry
> 
> On Sat, Mar 16, 2024 at 6:00 AM Les Ginsberg (ginsberg)  
> wrote:
> >
> > Bruno -
> >
> > Inline.
> >
> > > -Original Message-
> > > From: bruno.decra...@orange.com 
> > > Sent: Friday, March 15, 2024 11:17 AM
> > > To: Les Ginsberg (ginsberg) ; Barry Leiba 
> > > 
> > > Cc: draft-ietf-lsr-isis-fast-flooding@ietf.org; 
> > > last-c...@ietf.org; lsr@ietf.org; sec...@ietf.org
> > > Subject: RE: Secdir last call review of 
> > > draft-ietf-lsr-isis-fast-flooding-07
> > >
> > > Les, Barry,
> > >
> > > > From: Les Ginsberg (ginsberg) 
> > > > Sent: Friday, March 15, 2024 4:29 PM
> > > >
> > > > Bruno/Barry -
> > > >
> > > > In regards to:
> > > >
> > > > > > — Section 4.4 —
> > > > > >
> > > > >> Length: Indicates the length in octets (1-8) of the Value field. 
> > > > >  The
> > > > >> length SHOULD be the minimum required to send all bits that are 
> > > > > set.
> > > > > >
> > > > > > The SHOULD seems very odd: what would be a good reason to make 
> > > > > > it
> > > > > longer than necessary?  Is there a real reason not to 
> > > > > straightforwardly say, “The length is the minimum required…”?
> > > > >
> > > > > [Bruno] To be honest, that's just verbatim copy from
> > > > >
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > ta%2F=05%7C02%7Cbruno.decraene%40orange.com%7C5f1993bcf219469df
> > > 88808dc454cb26b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384614
> > > 42909928096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=yciJrdc6kkPK0A
> > > nYxylYSed89YvvvHWOtEAmK%2BHQXxY%3D=0
> > > > > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc8919%23name-application-
> > > identifier-
> > > > >
> > > =05%7C02%7Cbruno.decraene%40orange.com%7Ced0ce7f4ef6f4adb
> > > a5ee08dc
> > > > >
> > > 4504b6dc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63846
> > > 11337566830
> > > > >
> > > 44%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> > > MzIiLCJBTiI
> > > > >
> > > 6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=Mxn56QB9LdNA%2
> > > FBh2bAANCIsky
> > > > > Xx1zTir%2FIpTtpRsQbM%3D=0
> > > > > bit-
> > > > > At the time, I had assumed that copying an already agreed upon 
> > > > > sentence from an RFC was simplifier and safer. Looks like I was 
> > > > > only 50%
> > > right .
> > > > > You have a good point. I can't find a legitimate reason.
> > > > > I used your proposed wording (although my natural inclination 
> > > > > would have used a "MUST")
> > > > >
> > > > [LES:] The reason RFC 8919 uses SHOULD - and why this draft should 
> > > > do the
> > > same - is that sending additional bits unnecessarily is not 
> > > incorrect - it is simply inefficient.
> > >
> > > [Bruno] Agreed that this is only about efficiency. IMO the question 
> > > is whether the sender must be efficient or if there a good reason to 
> > > allow for inefficiency.
> > >
> > > > If you use "MUST" you are stating that receivers are obligated to 
> > > > reject a
> > > correct advertisement simply because it is unnecessarily long.
> > > > This is unwise and counterproductive.
> > >
> > > [Bruno] In theory, there should be a way to Be conservative in what 
> > > you send and liberal in what you receive.
> > > That would require more text. e.g.
> > > OLD:  The length SHOULD be the minimum required to send all bits 
> > > that are set.
> > > NEW: When sent, the length MUST be set to the minimum required to 
> > > send all bits that are set. When received any length below or equal 
> > > 8 octets MUST be accepted.
> > >
> > > Would this work?
> > [LES:] We have already explicitly stated what the sender SHOULD do - and by 
> > using "SHOULD" we indicate that the receiver needs to be "liberal" and 
> > accept the advertisement even if it is longer than necessary.
> > I do not see what is being accomplished here.
> >
> > An implementation that is optimal is already following the recommended 
> > behavior.
> > Do you think that by saying "MUST" you will get more implementations to be 
> > optimal?
> > I doubt it.
> >
> > And you now have to use two "MUST" statements:
> >
> > 1)For the transmitter - to be optimal
> > 2)For the receiver - to be liberal
> >
> > A single SHOULD accomplishes the same thing.
> >
> > I think this is "much ado about nothing" - or at best "much ado about very 
> > little".
> >
> >Les
> >
> > >
> > > Regards,
> > > --Bruno
> > >
> > >
> > > > As a WG member and co-author I object to this change.
> > > >

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

[Dongjie (Jimmy)]

Hi authors,

I just read this document. Maybe I didn't follow the previous discussion, but 
it seems in the current version it does not describe how this newly defined 
flag would be used by the receiving IGP nodes? 

Best regards,
Jie

-Original Message-
From: Lsr  On Behalf Of Acee Lindem
Sent: Wednesday, March 20, 2024 4: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] IPR Poll for WG Adoption for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Acee Lindem]

We have all the IPR poll responses. That was fast!

Thanks,
Acee

> On Mar 19, 2024, at 2:33 PM, Acee Lindem  wrote:
> 
> Co-Authors, 
> 
> Are you aware of any IPR that applies to draft-chen-lsr-anycast-flag? 
> If so, has this IPR been disclosed in compliance with IETF IPR rules  (see 
> RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> If you are listed as a document author or contributor please respond
> to this email regardless of whether or not you are aware of any
> relevant IPR. *The response needs to be sent to the LSR WG mailing
> list.* The document will not advance to the next stage until a
> response has been received from each author and contributor.
> 
> If you are on the LSR WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of
> any IPR that has not yet been disclosed in conformance with IETF rules.
> 
> Thanks,
> Acee


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

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

[Zafar Ali (zali)]

Dear chairs and the WG,

I have reviewed the draft and find it ready for publication.

Thanks

Regards … Zafar

From: Lsr  on behalf of Acee Lindem 

Date: Tuesday, March 19, 2024 at 10:59 PM
To: lsr 
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

[Lsr] 回复: IPR Poll for WG Adoption for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[linchangwang]

Hi Acee & WG,

I am not aware of any IPR related to this document.

Best Regards,
Changwang


-邮件原件-
发件人: Acee Lindem 
发送时间: 2024年3月20日 2:34
收件人: draft-chen-lsr-anycast-f...@ietf.org
抄送: lsr 
主题: IPR Poll for WG Adoption for "Updates to Anycast Property advertisement for 
OSPFv2" - draft-chen-lsr-anycast-flag-06

Co-Authors,

Are you aware of any IPR that applies to draft-chen-lsr-anycast-flag?
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

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

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

Thanks,
Acee
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Peter Psenak]

Hi Acee,

I am not aware of any IPR related to this document.

Thanks,
Peter


On 19/03/2024 19:33, Acee Lindem wrote:

Co-Authors,

Are you aware of any IPR that applies to draft-chen-lsr-anycast-flag?
If so, has this IPR been disclosed in compliance with IETF IPR rules  (see RFCs 
3979, 4879, 3669 and 5378 for more details).

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

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

Thanks,
Acee



___
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 AceeWG,I support the adoption of this draft. Thanks.Best 
regards,Zhenlin Tantanzl1@chinatelecom.cnChina Telecom Research Institute




--Original--
From:   
 "Acee Lindem"  
  
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

[zehua...@foxmail.com]

Hi Acee,
  
  Sorry for the mistake. I support  the adoption of this draft. It’s a useful 
extension for OSPFv2.

Thanks,
Zehua Hu
China Telecom

 
From: zehua...@foxmail.com
Date: 2024-03-20 15:27
To: Acee Lindem; lsr
CC: 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
Hi Acee,

  I support  the publication of this draft. It’s a useful extension for OSPFv2.

Thanks,
Zehua Hu
China Telecom

 
From: Acee Lindem
Date: 2024-03-20 02:43
To: lsr
CC: draft-chen-lsr-anycast-flag
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

Re: [Lsr] Intra-domain SAVNET method - draft-lin-savnet-lsr-intra-domain-method-03

[Qiuyuanxiang]

Hi Les and Acee,

  Thank you very much for your feedback.
  Regarding the two questions, my reply is as follows:
  1. About advertising protected prefix,
   When in a network with incremental/partial deployment of SAV, it is possible 
to identify which prefixes need to be used to generate SAV rules through the 
protection prefix.
   After receiving this routing information, it is up to the router to decide 
whether to differentiate and process it based on this sub-TLV, or whether to 
discard packets from unprotected prefixes.
   Of course, once all routers in the domain support SAV, all prefixes should 
be processed without the need for specialized protection prefixes.

  2. About advertising reverse cost,
The Prefix-reverse-cost sub-TLV is used to carry the total reverse cost 
from the router where the prefix is located to ABR in the inter-area network. 
If within the same area, it is not necessary to carry the reverse cost sub-TLV.
I have read the patent 
https://patents.google.com/patent/US11882019B1/en?oq=11882019.
I am not sure whether my understanding is accurate. It mentions the need 
for additional SPF calculation rooted at the other ABRs for the source area 
when inter-area, but does not describe how to get reverse metrics. I think it 
is still necessary to advertise reverse cost.


Best regards,
Yuanxiang



-Original Message-
From: Les Ginsberg (ginsberg) 
Sent: Wednesday, March 20, 2024 7:23 AM
To: Acee Lindem ; 
draft-lin-savnet-lsr-intra-domain-met...@ietf.org
Cc: lsr 
Subject: RE: [Lsr] Intra-domain SAVNET method - 
draft-lin-savnet-lsr-intra-domain-method-03

+1

The problem can be solved - and in a much more robust way than what is proposed 
in the draft - without any protocol extensions.

There is no reason for this draft.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, March 18, 2024 12:50 PM
> To: draft-lin-savnet-lsr-intra-domain-met...@ietf.org
> Cc: lsr 
> Subject: [Lsr] Intra-domain SAVNET method -
> draft-lin-savnet-lsr-intra-
> domain-method-03
>
> Speaking as WG member:
>
> Co-Authors,
>
> I see you have a slot at the LSR meeting on Thursday to present the
> subject draft.
>
> I believe this document is misguided. You shouldn't need to advertise
> protected prefixes. If you are doing Source Address Validation for
> intra- domain sources, why wouldn't you do it for all of them? What do
> you do for the intra-domain prefixes that aren't advertised (blindly
> forward them or summarily discard them)? If you were to only do SAV on
> certain prefixes, this should be a local decision as opposed to
> something that is advertised by the sources.
>
> Also, you shouldn't need to advertise any reverse metric. At least
> within an area, you have all the reverse costs in link-sate.  Incoming
> interfaces for asymmetric paths can be readily calculated without any IGP 
> advertisement.
> Algorithms to accomplish this are described in
>
> https://patents.google.com/patent/US11882019B1/en?oq=11882019
>
> The SAVNET WG shouldn't adopt any document requiring IGP advertisement
> without LSR approval.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
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

[zehua...@foxmail.com]

Hi Acee,

  I support  the publication of this draft. It’s a useful extension for OSPFv2.

Thanks,
Zehua Hu
China Telecom

 
From: Acee Lindem
Date: 2024-03-20 02:43
To: lsr
CC: draft-chen-lsr-anycast-flag
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] 答复: Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[zhao.detao]

Hi Acee and WG，
I support the adoption as co-author. OSPFv2 need the ability to advertise 
Anycast Flag. 




Original


From: AceeLindem 
To: lsr ;
Cc: draft-chen-lsr-anycast-f...@ietf.org ;
Date: 2024年03月20日 02:43
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

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

[chen.ran]

Hi Acee & WG,
I am not aware of any IPR related to this document.

Best Regards,
Ran




-


On Wed, Mar 20, 2024 at 12:04 AM Acee Lindem  wrote:

Co-Authors, 
 
 Are you aware of any IPR that applies to draft-chen-lsr-anycast-flag? 
 If so, has this IPR been disclosed in compliance with IETF IPR rules  (see 
RFCs 3979, 4879, 3669 and 5378 for more details).
 
 If you are listed as a document author or contributor please respond
 to this email regardless of whether or not you are aware of any
 relevant IPR. *The response needs to be sent to the LSR WG mailing
 list.* The document will not advance to the next stage until a
 response has been received from each author and contributor.
 
 If you are on the LSR WG email list but are not listed as an author or
 contributor, then please explicitly respond only if you are aware of
 any IPR that has not yet been disclosed in conformance with IETF rules.
 
 Thanks,
 Acee___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr