IETF Logo Mail Archive

Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 13 April 2017 08:32 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0950128B8D for <v6ops@ietfa.amsl.com>; Thu, 13 Apr 2017 01:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=swm.pp.se
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 pQFQARuZzfO1 for <v6ops@ietfa.amsl.com>; Thu, 13 Apr 2017 01:32:41 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 BEEDC12741D for <v6ops@ietf.org>; Thu, 13 Apr 2017 01:32:41 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63226A2; Thu, 13 Apr 2017 10:32:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1492072359; bh=mq2NTPH5Mexix0GAM/5nGmVT2CX4jCzlyKqRv/ZTjXg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tsj5skT26mCyktjWWiehELQCSRLCnAEwYOc2bSoE0ry4dem8UpClMVziaqJ0ryHmM LJrbZLy8BZveN22kRaxGiahmSzy/a4aXBoosMPnwfnGo4ppB+2TFjv3JJzpFMKN6a4 jiHt6b29kVDqL3QWpY1h8Xtel6XRZlU/EyWAOfsA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4B41188; Thu, 13 Apr 2017 10:32:39 +0200 (CEST)
Date: Thu, 13 Apr 2017 10:32:39 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: "v6ops@ietf.org" <v6ops@ietf.org>
In-Reply-To: <ED7BCBE5-C124-4BB4-B42A-D857EC85E484@consulintel.es>
Message-ID: <alpine.DEB.2.02.1704131022210.27978@uplift.swm.pp.se>
References: <D8F5C737-B01A-4EC8-9175-C4921C0CD69F@consulintel.es> <392D675B-73C4-40D3-81A8-A06907F5581D@employees.org> <3BBFC922-85BD-49B5-B39E-227F191BD48C@consulintel.es> <729244A1-E7AB-4BA0-8B39-A6122D2C32DB@employees.org> <CAD6AjGQyatWEOxCpnOn8H+SxG=BWM=cBPaXoON6vA7dj7TNqOQ@mail.gmail.com> <72F5C80C-DDB5-422E-8FEC-7D4157722780@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19757@GAALPA1MSGUSRBF.ITServices.sbc.com> <E181152D-C33F-418A-85BC-4F7829BEE16F@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DB19CFE@GAALPA1MSGUSRBF.ITServices.sbc.com> <E3C498E3-25FC-4612-B565-98818DB60AB8@consulintel.es> <ED7BCBE5-C124-4BB4-B42A-D857EC85E484@consulintel.es>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-475143714-1492072359=:27978"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/KOzIVKzl_B5iDhJvyQ3mmadS6ac>
Subject: Re: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 08:32:44 -0000

On Wed, 12 Apr 2017, JORDI PALET MARTINEZ wrote:

> The CE router MAY support 6in4 functionality.  If 6rd is implemented, 
> 6in4 is already supported as well, as the underlying protocol/technology 
> is the same, being the only difference, having the mention of “6in4” in 
> the GUI/CLI (just an example) if it is being configured manually, or 
> even stating that in the relevant documentation. In other words, no 
> additional code is required for the support of 6in4 when 6rd is already 
> supported

In the original 6RD-2 requirement that talks about user configuration, for 
configuring 6in4 the UI would need to look slightly different, right? 
Depending on some choices in UI, some input methods of the parameters 
might not work with 6in4.

So I guess your intention to include 6in4 could be done either as a new 
transition protocol with SHOULD, or it can add an additional MAY 
requirement in 6RD that the settings be compatible for configuring a 
generic 6in4 tunnel as well. The above text seems to be the latter?

I think it would actually make more sense to create a "new" transition 
technology in there in that case. That would keep it clean the way I 
interpret Barbaras intention is?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

v2.23.0 | Report a Bug | By Email