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

Mark Smith <markzzzsmith@gmail.com> Thu, 07 November 2019 01:21 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6158412008F for <ipv6@ietfa.amsl.com>; Wed, 6 Nov 2019 17:21:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWpZityIADe8 for <ipv6@ietfa.amsl.com>; Wed, 6 Nov 2019 17:21:43 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74348120045 for <6man@ietf.org>; Wed, 6 Nov 2019 17:21:43 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id v138so501467oif.6 for <6man@ietf.org>; Wed, 06 Nov 2019 17:21:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CcaJuFFhQkpt0FR8EGPCiIs/wtL7AqSdgsDiEBk667I=; b=fgI2Dm7xP+bgJ6BgVVhIuptIKT1ArnDmGEFJmE7wB4BvgeKWRGrNWy67F9N1WJbrM6 2kNPQub4XDqA4wl3KIV3LDrgrjDt/W6ce1EVdg0o+IdP/R6k+qT6BC1hRysjpuHhYW9x 9rIWWFfEndX2DVEc0BuKmCBIGYWeZrOZ39YwneQyXQG5YmYMpRLIildBHwbEtbULWlV9 arFoBWai8qNsK3FxIAuZSpA+X9FX4aGMY4Elmu24IwKKvsFvKf99BpEfjkc/N9jfciCZ rw0+ErgI99u/XnB14nJeM3vaj+rACYazRDZrl81o0WCQebCfGLKXha7w2Rr2qMh/s6oz rblg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CcaJuFFhQkpt0FR8EGPCiIs/wtL7AqSdgsDiEBk667I=; b=XwdBBGqp15m/aXtM4t5c/JeprXdnF4ekrBvTw7ZeZhM7azRGM3s20eGyR9NZaT/Nii ZyLzyfsYTM+Vt/IRZDIunl9lWe+xbaiy4XUy3gU07onoBzMvlhaab6cYD7S4MhXax3xq P2OoV9uvwZ53fbTx2lTGLUziVln1x1v0pLDigdX9gmoc0m7feGQKLDHrSO/x/7tlkLsl +ofmjpFBoS6UMDGI/lzLYwM9okyVUFto4Jhi0THniUmpLAX8NBw9KTIjr5ED+jMddp6a F3Ud9QCZ5Beqs+F2bd75eeD0wA1nC0QfqccHQayrHFhg33eusbp1PzqyXhQSW5yNLiPp cgmA==
X-Gm-Message-State: APjAAAVcGJkG5G9AsxCEhRnHCJD+lUCMAYX4GgWxPoIa3eO3vyHaPDYM thvSlysEsMSiqg8nYVBWqpDxM+VgPj3bPXnvh1h3zw==
X-Google-Smtp-Source: APXvYqwA6iKg0fDu8A6sr6zL1WZmw35X7h+ckPi/+WxAF00lO9XbnvBMfgW1N5UvmB7E1xHUEyQAs0FGbWH8lv+FiBY=
X-Received: by 2002:aca:5691:: with SMTP id k139mr908415oib.54.1573089702588; Wed, 06 Nov 2019 17:21:42 -0800 (PST)
MIME-Version: 1.0
References: <157277906705.13535.345852921709779212.idtracker@ietfa.amsl.com> <CAO42Z2wSU-puDaQq-PzTCTE=S3qyqUNrPhH0pgOEO_d3=StnHA@mail.gmail.com> <b97c15c0-b1fe-0d78-0897-5fc4bb6a9a34@foobar.org> <B42E6EED-5620-49BE-BB3D-B1CF6F04A1CC@gmail.com> <20191103212712.GK2287@faui48f.informatik.uni-erlangen.de> <B2A9EAB8-BF52-4302-BB77-70EE252F45E5@gmail.com> <24313.1572827211@localhost> <CAO42Z2y_qpaxMz86Oj6E5OHJr_whJit_2P7zwqNK3CbrKSZhyg@mail.gmail.com> <CAMGpriU_p7RG9rDrqONgWAiw+cqvuQ4ktSFD6H9SL5gfDSnrzQ@mail.gmail.com> <1D216F6C-38B0-412C-B089-FC03B5DC68AD@gmail.com>
In-Reply-To: <1D216F6C-38B0-412C-B089-FC03B5DC68AD@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 7 Nov 2019 12:21:16 +1100
Message-ID: <CAO42Z2zM6rncxVJGaz7p64jahbK9FsiRRm5iOaRAEzgJi9g85w@mail.gmail.com>
Subject: Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Erik Kline <ek.ietf@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, 6MAN <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NfZD7udDuJd_PDM4ngiu7qhBrV4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 01:21:46 -0000

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