IETF Logo Mail Archive

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

Fred Baker <fredbaker.ietf@gmail.com> Wed, 12 April 2017 17:10 UTC

Return-Path: <fredbaker.ietf@gmail.com>
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 F409B12EB06 for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 10:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BCA3uHFuePdD for <v6ops@ietfa.amsl.com>; Wed, 12 Apr 2017 10:10:43 -0700 (PDT)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 15D7512EB02 for <v6ops@ietf.org>; Wed, 12 Apr 2017 10:10:43 -0700 (PDT)
Received: by mail-pg0-x243.google.com with SMTP id g2so6528097pge.2 for <v6ops@ietf.org>; Wed, 12 Apr 2017 10:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vy9B1Bc6BYN08Gbv2RIVi99E7Xz4dDRABthZO5zj+K0=; b=oxoGt/24hs8T9Mdk9u5d4y9Cs+gIMCXiDo1EuRHR7W+qVWXAbyKTPiJ9R08NkrOfED 1r1Owti8POwvuGuD0fEzH0bOXY69BoxA1PqChnmyvtcgXvXHjtov8Hu7L0FqbuFCA5R9 lnPunf1MEzvKADlPEzGVc/Bf/yKPz8phQ62u8ZxD8lHkA3EnRCieSwYZBCEiXsmNkS9e dxZX0ontcmJZY/S90gmHlTIQuLRIwAuC+/CttO0ZnEcxIUG6927uKbGWQT9ac/DHD4N3 +7v/wYO0ftENwIoHHLM0IlybiZqqv6ovVyCEfPOJZ9MivncghhQPNLDB43L5qmVQHLev LpIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vy9B1Bc6BYN08Gbv2RIVi99E7Xz4dDRABthZO5zj+K0=; b=cVhe/2GuhYfv3LulVKUNLMP8cfza3NG0jf19nNHjhm6E/Sue/3qSvADtqaPAAurX0f kXDE3t2oC0BMNYtaQWdLL/V0oiaZSHT30+1yJdst5YxWeS4jloiWKdTB0T/Rkq2Bfibr YMyh64aCJpYo0X8I+FJtoP/quqGLVLIytXc4fwlYkdDy89uaioBgYxwevk5GxVbZKGjQ UDXLVYsScXQpiL/IHRnErrgXfKXWxZrDnuwoV3uTQMxh7li6RR14DGHWM/Npy6Nuv0sO b4pv2k387lnzyj7VmNsRh6ugzI5fvWZsoBHRcD14xP66UPUdv25GPN/OT6g306j2SP4I PtFA==
X-Gm-Message-State: AFeK/H2sLYjR0UXD+ZcHT2zmCpOUV2xH2bP6foQh4JM3qGpeT4ICsR8RdOcLDFko2Sahng==
X-Received: by 10.98.19.12 with SMTP id b12mr67770509pfj.21.1492017042635; Wed, 12 Apr 2017 10:10:42 -0700 (PDT)
Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id z21sm15903316pfk.95.2017.04.12.10.10.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 10:10:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Date: Wed, 12 Apr 2017 10:10:40 -0700
Cc: "STARK, BARBARA H" <bs7652@att.com>, "otroan@employees.org" <otroan@employees.org>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5542863A-9BA7-48A6-B114-52E13EA89380@gmail.com>
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> <787AE7BB302AE849A7480A190F8B933009E4C3B8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DB194A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <787AE7BB302AE849A7480A190F8B933009E4C4D9@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Di7WYWCs8GCnBO72zPhCHoPR-tM>
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: Wed, 12 Apr 2017 17:10:45 -0000

> On Apr 12, 2017, at 6:12 AM, mohamed.boucadair@orange.com wrote:
> 
> Hi Barbara, 
> 
> Wouldn't just be fine for those ISPs not interested in transition mechanisms to continue referring to RFC7084?

The tricky bit tends to be in how we label the update. If it "obsoletes" or "updates" 7084, we mean that any reference to 7084 becomes a reference to the new thing, or 7084 plus the new thing. We would need to clearly label it so that a procurement could reference 7084 without it, or reference 7084 and the new thing separately.

> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : STARK, BARBARA H [mailto:bs7652@att.com]
>> Envoyé : mercredi 12 avril 2017 14:53
>> À : BOUCADAIR Mohamed IMT/OLN; otroan@employees.org;
>> jordi.palet@consulintel.es
>> Cc : v6ops@ietf.org
>> Objet : RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00
>> 
>>> I tend to agree with you but with a slightly different proposal:  pick
>> ONE
>>> mandatory stateful mechanism (DS-Lite) and ONE mandatory A+P
>>> mechanism (MAP-E).
>> 
>> Because RFC 7084 is also used as a mandatory reference in BBF TR-124 (used
>> by telco ISPs to help with CE router RFPs), and most ISPs have no interest
>> in requiring capabilities that are not useful to or relevant in their
>> deployment, there MUST NOT be any mandatory transition mechanisms included
>> in a 7084-bis.
>> Barbara
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email