Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Sander Steffann <sander@steffann.nl> Tue, 26 May 2020 19:52 UTC

Return-Path: <sander@steffann.nl>
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 E07C13A0FBA; Tue, 26 May 2020 12:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
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 lmwgnCWwvWmG; Tue, 26 May 2020 12:52:15 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:9e0:803::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B5A3A0FB5; Tue, 26 May 2020 12:52:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A0CF049; Tue, 26 May 2020 21:52:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:in-reply-to:references:message-id:date:date:subject :subject:mime-version:from:from:content-transfer-encoding :content-type:content-type:received:received; s=mail; t= 1590522731; bh=rMjVniQBbWtd600zwe69fbrAe+LcXjAdEHF/bWC0eCQ=; b=a RbirHlyz/fAQgPZ/esSYF34yIJbG1ZD/H0Ohc/CyVXg7QcojeXd6j03+cGpf/Z0T Bl1q7YUhrdwjseq/UgQ0wqZmQp7QwKCq2Z+pDfbphhuXvHubsj5JIrlSiwOKudFZ Pj+XZLZx66MECERyg7Gn0as9ypkFfapDSKTjRf/2Hc=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id O_Ul5AietVKK; Tue, 26 May 2020 21:52:11 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:4047:9a1c:3280:98fe] (unknown [IPv6:2a02:a213:a300:ce80:4047:9a1c:3280:98fe]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 4D1EF3C; Tue, 26 May 2020 21:52:11 +0200 (CEST)
Content-Type: multipart/alternative; boundary="Apple-Mail-95E3B1CE-ABA1-434F-A353-D1725E932BA7"
Content-Transfer-Encoding: 7bit
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Mime-Version: 1.0 (1.0)
Subject: Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Date: Tue, 26 May 2020 21:52:10 +0200
Message-Id: <5265F3D0-BAB8-41E3-B932-85ED4DEDA468@steffann.nl>
References: <CAOj+MMHRAuT1931reBLe-1UQ5gac4RmCtybk-OXn03atoAjDkA@mail.gmail.com>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
In-Reply-To: <CAOj+MMHRAuT1931reBLe-1UQ5gac4RmCtybk-OXn03atoAjDkA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (17E262)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7Bzy-5GTBandixCYPDs1oFD86wY>
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: Tue, 26 May 2020 19:52:17 -0000

Hi,

> draft says: 
> 
> Is designed to operate within a network domain. 
Source and destination are in the same domain. Who says that the domain is contiguous? Let's change the example to main and branch offices. Same administrative domain, while still traversing the internet.

Cheers,
Sander