Re: [Int-area] ILA and int-area
Behcet Sarikaya <sarikaya2012@gmail.com> Thu, 18 May 2017 01:36 UTC
Return-Path: <sarikaya2012@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED90129405 for <int-area@ietfa.amsl.com>; Wed, 17 May 2017 18:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9oP9rTZ9Fpl1 for <int-area@ietfa.amsl.com>; Wed, 17 May 2017 18:36:38 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 33DEE129431 for <int-area@ietf.org>; Wed, 17 May 2017 18:36:38 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id l50so22686411wrc.3 for <int-area@ietf.org>; Wed, 17 May 2017 18:36:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=b9J7m0EDm99O5uc8so0GF5QRAtKPvjhNPvK32LerXKw=; b=NvdlqykNogiyO9pawnR4bg+27gOXb/CWziqFf2fwQPvtkBZGZptVnbywuVSV8Jjxgj 6EC/K0IXGV5mqGpR79LwZUfqj+gvJVEd+ts8EPt21OSVuISV4INmc4QponVWjkd2ciHX xYrj4s54oOCn9q6lLX0QFsnDVCRYcz10iH26b30GCV5iC8N88oQImF2mmadLH9bZYG39 1iHRK5haB6w7Sc/xwBVCMmldKrXtNF6yEgLNSgOkz0wpGJoHygEuDMqk7FoCvng5G0rJ zA49A9k5Gkt06X7UJbTVgNYm1NRz4Y9OCkFJkI0GifEluOvnCp+tz3WOsq2ifyjBa9/p EzLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=b9J7m0EDm99O5uc8so0GF5QRAtKPvjhNPvK32LerXKw=; b=hSc1awx+iOAwxRsfSS0S+VbA0DT3FsZlZaDmX3m9Tqegdj+Yq5RerAJ9Enjd8pKT7R oOCMoTuseIlahXBHS0CWxQdgib1M+MMvXdt4RdMjR2TueyFSxwYGbrSt8Kg/0HwWRJk8 V8YpjQ/NLWdJMQotgCLIm1VN13YilSwJ7HIZBmaOWA0QouR2tB9XK+oc2ke/H5nHH4YC Axxx7AAnM57Y2k2oCdSAKkEmUXVRD5R6FandaLZNz1VjL75CMku+eiCdm9DnTUva2MCJ 4QqUt4OecT7utOfhMvjVEgJ+RFzT5GXHhaGt9e29EHU6tqK1rD36UQsYbVowY2NnfIpc Kk/Q==
X-Gm-Message-State: AODbwcCyba9qbjajLuu8u4Znjtq4XsYIsRnMyIzz5rs6Mqe7r7zxRP9a lWDmLjecTkxVvMesAggofZOvyg73qw==
X-Received: by 10.223.172.165 with SMTP id o34mr966752wrc.155.1495071396764; Wed, 17 May 2017 18:36:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.134.125 with HTTP; Wed, 17 May 2017 18:36:36 -0700 (PDT)
Reply-To: sarikaya@ieee.org
In-Reply-To: <3428e7ea-ed1b-1418-b160-7db4a72d6557@joelhalpern.com>
References: <CALx6S34A5k_DtEb7YWQs=Y79p4rCpe-9Hg3_YiqbOSyWzqepYA@mail.gmail.com> <813a6560-4513-958a-0898-d42133285a34@joelhalpern.com> <CALx6S35bMXCrVuH-8+oNCuq+Aw0Fw4cL-hGpVfX9E3QHaxGG7w@mail.gmail.com> <CAAedzxox77q+u5XpjSX3_UwLfrNoUymdO0TvDZYYD2adb9NfiQ@mail.gmail.com> <c508e974-b979-a1e3-8fa9-a53d5840e730@joelhalpern.com> <CALx6S34y6mzmq6S2_NMUTxwYEd_Xvks4RLpDUS_OoQkwHt-e-w@mail.gmail.com> <3428e7ea-ed1b-1418-b160-7db4a72d6557@joelhalpern.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Wed, 17 May 2017 20:36:36 -0500
Message-ID: <CAC8QAcfu35YugR7pDCaz2aV6OgnJizNCr-co=MmTgZOyXN5ZrA@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Tom Herbert <tom@herbertland.com>, Petr Lapukhov <petr@fb.com>, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: multipart/alternative; boundary="001a113c456c84a5e3054fc26f50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/QaUY7KSfUWD-AB---TOr8TAO82Y>
Subject: Re: [Int-area] ILA and int-area
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 May 2017 01:36:41 -0000
On Wed, May 17, 2017 at 8:35 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote: > I do not think classic Internet tunnels (e.g. IP in IP or GRE) are a good > comparison for ILA. The ILA mapping requires dynamic knowledge about the > remote end. (One of the things that is important about ILA is its ability > to hide dynamics.) > GUE at least is proposed specifically for use in data centers. > > I don't think this discussion, i.e. Tom's request to intarea was related to GUE which is already a WG draft. Also GUE is not specifically proposed for data centers, but it could be used in data centers with certain extension headers. I still think that especially if experimental/standard track is used means to manage ILA would be needed. My two cents :) Behcet > I think you understand my point, so I will not belabour it. > > Yours, > Joel > > > On 5/17/17 1:53 AM, Tom Herbert wrote: > >> On Tue, May 16, 2017 at 8:33 PM, Joel M. Halpern <jmh@joelhalpern.com> >> wrote: >> >>> If we want the documents to be informational, then it should be about a >>> context where we understand how to build the surrounding infrastructure. >>> For example, if it were documented for data centers, based on Facebook's >>> experience, I would have trouble objecting to informational publication. >>> >>> If we do not know where it applies, and what to try it out in various >>> contexts with various control setups, then that sounds like experimental >>> RFCs. While I have my doubts about some of the applicability, that >>> should >>> not stop useful experimentation. >>> >>> But an informational document that says that this can be used (roughly >>> speaking) ~anywhere you can figure out a way to control it~ seems a bit >>> odd. >>> >>> Okay, thanks for the clarification. It seems like either experimental >> or standard would be appropriate then. The other aspect that could be >> relevant is there is no change to on the wire protocol, I'm not sure >> how that would impact the track status. >> >> As far as how to control it, I would point out that neither GRE nor >> IPIP, probably the two most common encapsulations in use, don't >> specify an associated control protocol. We are taking that same >> approach with GUE and I think that same approach is good for ILA. It >> would be great to see a common control plane for tunneling and >> virtualization that solves the larger common problem (this is why >> IDEAS is exciting to me), but even if that existed it would never be >> the only means to control the dataplane. In some deployments simple >> configuration is more than sufficient, for example. >> >> Thanks, >> Tom >> >> Yours, >>> Joel >>> >>> On 5/16/17 11:25 PM, Erik Kline wrote: >>> >>>> >>>> >>>> >>>> On 14 May 2017 at 03:21, Tom Herbert <tom@herbertland.com >>>> <mailto:tom@herbertland.com>> wrote: >>>> >>>> On Sat, May 13, 2017 at 11:03 AM, Joel M. Halpern >>>> <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote: >>>> > It appears to me that there are contexts in which it is likely >>>> that >>>> ILA is >>>> > useful. >>>> > >>>> > Using the example of the progression of LISP, I have concern with >>>> the >>>> > current approach of NOT spelling out how and where it would be >>>> used. >>>> LISP >>>> > started out as experimental in significant part because it was not >>>> clear >>>> > where it would be useful. We re now progressing it to PS with a >>>> clear >>>> > context. And that context is NOT Internet-wide deployment for >>>> Internet >>>> > scaling. Because that deployment problem is REALLY challenging. >>>> > >>>> > As such, if ILA wants to either be developed for the data center >>>> context or >>>> > be developed as an interesting experiment across a range of >>>> potential uses, >>>> > I can not object. >>>> > >>>> > I do have problems moving it forward towards standards track for >>>> some >>>> > unspecified but general use in its current form. The dependence >>>> of >>>> the data >>>> > plane protocol on the information distribution is so strong that I >>>> do not >>>> > see how the general case can be treated. >>>> > >>>> Hi Joel, >>>> >>>> Intended status is listed as informational if that helps. >>>> >>>> I tend to think that the relationship between an ILA data plane and >>>> control plane is analogous to the relationship between the IP >>>> protocol >>>> and routing protocols. Yes, there is a strong dependency on having a >>>> control plane, but mandating a specific control plane as part of the >>>> core protocol reduces flexibility and extensibility. >>>> >>>> >>>> Put another way: the domain of applicability is the same as the >>>> domain(s) over which the control plane operates. Any ILA packets >>>> outside that/ose domain/s should just look like vanilla IPv6. >>>> >>> > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >
- [Int-area] ILA and int-area Tom Herbert
- Re: [Int-area] ILA and int-area Joel M. Halpern
- Re: [Int-area] ILA and int-area Tom Herbert
- Re: [Int-area] ILA and int-area Erik Kline
- Re: [Int-area] ILA and int-area Joel M. Halpern
- Re: [Int-area] ILA and int-area Brian E Carpenter
- Re: [Int-area] ILA and int-area Tom Herbert
- Re: [Int-area] ILA and int-area Behcet Sarikaya
- Re: [Int-area] ILA and int-area Joel M. Halpern
- Re: [Int-area] ILA and int-area Tom Herbert
- Re: [Int-area] ILA and int-area Behcet Sarikaya