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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 06 November 2019 21:33 UTC

Return-Path: <hayabusagsm@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 75C2812004C for <ipv6@ietfa.amsl.com>; Wed, 6 Nov 2019 13:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8zmCKR-D1DIe for <ipv6@ietfa.amsl.com>; Wed, 6 Nov 2019 13:33:00 -0800 (PST)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 4879B120047 for <6man@ietf.org>; Wed, 6 Nov 2019 13:33:00 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id 30so372675qtz.12 for <6man@ietf.org>; Wed, 06 Nov 2019 13:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wfoSJV83M8mdi7VB0JjdpISEE53bHIYMs0ahCzb4I7k=; b=iRH9TU0G80CI6Mrh86vplxWPH3qTYjzHfLmwMSQlxlPy1LEix1tBeKAER2i6XpozVp cJk5G7DpUoTHe9bFsCGZCpaYwrx8vFrhgoapUxVa4fjsnPCX+k39PFOzNRJLGflp+XoY dOHXIUOSeRKOwivnjKPtzeHZMrRzT8oVzVXSMUYsdO/IzajH0SwOIcVMzRkg22M4+rDv dvQJGd6jTPss0lXt8Si4n2Q7TqsTcM8NmEIkL3ElWkwDxL+sIQQI7nOqmvqCEtwY0xAu oDi4P1IdIeE+Xiap+dQcEKDKKRnkv1PIGtbTgyCxibCI7dMbl8nlxEL8tbJqFex5J6fc mDLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wfoSJV83M8mdi7VB0JjdpISEE53bHIYMs0ahCzb4I7k=; b=CxiIyfpZm+qEte6Zv6OfqiCbpGrqFBJkl6HSLDQUrhjfewqrNL7E5qS5/7dWEKiU8f VqkV/G1mBv/OGxp4L9xRO8fdi4uxm9lyCMBE2X2dukGAJ8stWlfe3MH+Oj4vTLJsAzsq r5UXIF57OzrwKQ2hMS5N3GX+C0RIxX1IkCAOPqDgyNNmS7vO13pCH7AESNYC0WIufif4 RtQrC6guXxPfq8Wu6HuAseeEIz9k1kfAlR4zctUKOW/Si4sAbSvKDEbwwt1XP9njs028 hdd6JUTIYBh2tLIIU+p2g2yri5sTBBSg75VpWhwp+iqjAWPRUXt56EmoaJSSKcWQL8f7 R/Bg==
X-Gm-Message-State: APjAAAXHcUbBVxmKaz6KemRWnKGAaFf+Q79CyN3RLp4eEsijJwbwuNaF YUFfEO75bNZZcJwK3T+HjpY=
X-Google-Smtp-Source: APXvYqxfLp4FILtWHbjBHxGDrwPNP4ptCWLRQWWbgnMRCdQe/zPl5dGM46JV1B8W+468ZaUXlDq20Q==
X-Received: by 2002:ac8:6f7c:: with SMTP id u28mr65464qtv.273.1573075979108; Wed, 06 Nov 2019 13:32:59 -0800 (PST)
Received: from [192.168.1.213] (pool-72-83-194-140.washdc.fios.verizon.net. [72.83.194.140]) by smtp.gmail.com with ESMTPSA id d145sm31470qkc.120.2019.11.06.13.32.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 13:32:57 -0800 (PST)
From: Gyan Mishra <hayabusagsm@gmail.com>
X-Google-Original-From: Gyan Mishra <hayabusaGSM@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-80C9A2CE-9B2C-40B0-AC02-0C387536A959
Mime-Version: 1.0 (1.0)
Subject: Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <CAMGpriU_p7RG9rDrqONgWAiw+cqvuQ4ktSFD6H9SL5gfDSnrzQ@mail.gmail.com>
Date: Wed, 6 Nov 2019 16:32:56 -0500
Cc: Mark Smith <markzzzsmith@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, 6MAN <6man@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <1D216F6C-38B0-412C-B089-FC03B5DC68AD@gmail.com>
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>
To: Erik Kline <ek.ietf@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-sC-uB3hieyTjH9ZVoXSv-P0Pv0>
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: Wed, 06 Nov 2019 21:33:02 -0000

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.

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