Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)

In-line 

Gyan

Sent from my iPhone

> On Nov 6, 2019, at 8:21 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
> 
>> On Thu, 7 Nov 2019 at 08:33, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>> 
>> Mark
>> 
>> After reading through the draft and reviewing this thread my thoughts are that this could be a new feature not available in IPv4 now available in IPv6.  So I think the difficult part is the problem statement and what you are trying to solve with this new anycast range.
>> 
>> You mention that the major benefit which you stated as problem you are trying to solve is  that in general address space overlap is a routing issue and with anycast you have multiple devices advertising the same service VIP host route but because it’s unicast its not “well known” defined formal  anycast space that would trigger network engineers to believe that its an address overlap routing issue when its not.  What does make the unicast space use of the anycast function possible is that its almost always a host route.  Also it’s in fact not really address overlap in that you can in a multi  homed environments you can have the same nets advertised my many sources and that’s valid and does not cause a routing issue.  Imagine a use multi homed use case where you have a customer multi homed into an MPLS core and the customer decided to make all entry or exit points equal bgp attributes advertised into the core.  So now the core bgp best path tie breaker lowest IGP metric breaks the tie and so based on where you attach to the core you take your bgp valid/best unicast path to the destination.  So there maybe cases in a multi homed environment where you what to have active/backup routing or multi active but want to be optimized so you set bgp communities at your edges and can match and prepend with a specific pattern for geographic optimal low latency  routing.  So my point is that because you have multi homed scenarios exist where the same set of prefixes are advertised by multiple sources at the edge into the core that is no different then using unicast for the anycast function where an anycast service VIP using unicast space is advertised my multiple sources.
>> 
>> Unicast has been used for anycast services for decades and I have engineered deployment strategies to many of my customers where all NMS related router services such as DNS, NTP, Netflow, syslog, snmp are all done via unicast.
>> 
>> It works great and no routing issues or complaints.
>> 
>> So if you can provide the same functionality anycast service via unicast space why burn a /8 for nothing with not much gain as there is no problem being solved here.
>> 
> 
> Have you ever deployed anycast?

[Gyan] See above.  I have many successful anycast deployments using both unicast IPv4 or IPv6 address. No issues.  From a routing perspective since the formal anycast prefix is routed like any other unicast anycast prefix it makes it more cumbersome to have to use a special formal range for anycast then using the unicast prefix routing range.  From a routing perspective it makes it easier for the anycast to fall in the unicast range already allocated for the edge CE and already being advertised in the core bgp rib.  The anycast advertisement is generally in the implementations I have worked with in the anycast deployments was done on a Load Balancer Citrix Netscaler that runs bgp to the up stream data center router and advertises the host routes and uses a feature called “host route injection” so if the service VIP for the anycast service goes down for let’s say dns or ntp the host route is withdrawn and then in the core from a proximity routing perspective now take the next best closest anycast service advertisement as the unicast path to the service vip.  Using unicast range for the anycast service worked really well and I have deployed to many of my customers.
> 
>> Gyan
>> 
>> Sent from my iPhone
>> 
>>> On Nov 4, 2019, at 6:33 PM, Erik Kline <ek.ietf@gmail.com> wrote:
>>> 
>>> Host Identity Protocol could have also achieve this.
>>> 
>>> I've started to wondered if solving the identifier/locator problem
>>> within the transport layer, using temporary transport layer connection
>>> identifiers - a  32 bit 'token' in MPTCP, rather than persistent host
>>> identifiers, might be the better solution. It's certainly has been
>>> much more successful at being deployed - Apple put MPTCP in iOS 7 and
>>> it was being used for Siri (don't know if it still is).
>> 
>> 
>> Add to this QUIC's connection id(s).  I quite like some things about HIP, and in general I think that at this point implementing a "session layer" via these MPTCP/QUIC -style mechanisms is the best path forward.
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------