Robert – For the most part, I think it is most appropriate if the authors of the draft respond to questions – and I think Ketan has been doing his best to do so.
Since you have specifically targeted your questions to me, I will respond with a few points. I fail to understand why you and others on this thread seem to require a definition for “anycast”. It is as if you don’t understand what the term means – which is quite surprising since you have many years in the networking field. This draft (nor other IGP drafts which have defined the equivalent functionality) is not inventing a new definition of “anycast”. The draft is just defining a way to mark a given prefix advertisement as being an anycast address. Marking an address is an indication of the operator’s intent i.e., it is saying that it is possible that this address will be associated with multiple nodes. It is true that such an intent can also be derived by examining the LSDB and seeing if multiple nodes are originating the same advertisement, but that logic does not detect the case where an address is intended to be anycast, but at a given moment only one node is originating the advertisement – possibly because the operator has not yet brought up other nodes yet – or some nodes are temporarily down – or configuration of the network is in progress. As to use case, one example (which I think Ketan has already mentioned) is when calculating repair paths. You would not want to use an anycast address for a node on the repair path because forwarding of packets to that address could be sent towards multiple nodes. Les From: Robert Raszuk <rob...@raszuk.net> Sent: Friday, March 22, 2024 7:33 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Acee Lindem <acee.i...@gmail.com>; lsr <lsr@ietf.org>; 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 Les, > Knowledge of whether a given prefix is Anycast has proven useful in existing > deployments Would you be so kind and enlighten us with a few practical examples in which you exhibit practical usefulness of this flag at the IGP level? More basic question - is this set by CLI or is there a special protocol algorithm which set such flag ? If it is the latter, can you explain it ? So if suddenly one src of such anycast goes down rest of the area still thinks it is anycast ? From the BGP side of things indeed for basic IPv4/IPv6 concept of ghost loopbacks were used as next hops which indeed were advertised as anycast addresses. Is that one example in which you would hope that BGP prefers a path if the next hop is an anycast address as told by IGP ? And you push that "automation" to operators to prefer such paths by manual configuration ? And to second Bruno's question - what is IGP's definition of an anycast address ? Many thx, Robert On Thu, Mar 21, 2024 at 7:47 PM Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> 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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of > Acee Lindem > Sent: Tuesday, March 19, 2024 11:43 AM > To: lsr <lsr@ietf.org<mailto:lsr@ietf.org>> > Cc: > draft-chen-lsr-anycast-f...@ietf.org<mailto: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<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
