Hi Les, > I fail to understand why you and others on this thread seem to require a definition for “anycast”.
Asking for definition of "anycast" has a different reason ... Which is to validate all network conditions which may result in having the same address advertised by more then one node. Being IGP area node, ABR (summary injected via two ABRs is an anycast), ASBRs (redistributed 3017 routes to IGP + LDP by two or more ASBRs is an anycast etc). That is why I think it is important to a bit scope the meaning of the proposed herein flag. Or at least to say that this flag applies only to manually configured addresses on more then one node. Many thx, R. On Fri, Mar 22, 2024 at 5:48 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > 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> 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> On Behalf Of Acee Lindem > > Sent: Tuesday, March 19, 2024 11:43 AM > > To: lsr <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 > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
