Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt

Tom Herbert <> Wed, 15 August 2018 00:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE881130E1E for <>; Tue, 14 Aug 2018 17:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZpzQ1lldg5iV for <>; Tue, 14 Aug 2018 17:01:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 764F3126F72 for <>; Tue, 14 Aug 2018 17:01:01 -0700 (PDT)
Received: by with SMTP id m13-v6so23138800qth.1 for <>; Tue, 14 Aug 2018 17:01:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r/kou4VTenmL0mMnA2+Rgq/NLQ47C9c4N9XNsxDuALc=; b=SojbeC6uCLILr3XMRzPl0dLz1i6AMENd5CKp4J1b2nE5CHd7dZGTo7Wgps+1EVMxvI FJ1wgSivqgqN7mrH/axU/+/qP7qgv0zlLbg/szt+RQ1rANN2DFMIipeids9nonAYv2VX /WIGqK/9s2/h5cwepzHKCWRfKF5o+NYxe8gh1eGvWw6L5z03wrFHKZ1aIz2tjHMFee/j GACbqwX7DWhnukuBjPuy1aegua8qOL7R/nVhkRaSSQmtMmXc+8Ttx48+/2lp2v5toaAz kgE+SVtB/5IV2L3dtu91SLGyrjs6QYH/2oz/lxEhsCyADsrjnWpV0eBcfMGe03O0us8m zzNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r/kou4VTenmL0mMnA2+Rgq/NLQ47C9c4N9XNsxDuALc=; b=SHNxZy0NXGl3aZPmAmu2H8EgXS6eVlRgFRbvshMLuEA4loMIg6TsIDgB+nEuYpnkuw Ba8Yd+GaWQKfGD3DI1TsxD4nXcg2QGpX0gpGtEpqtgCCmkHAubs8HhPZCK2PrIfEzKTp zGFIDHmE9dIpKVQW+toAQ5aNn7yaoT+gfFzWvZiBFyFogvXYbPxbAxFatqX795ey80ND IvUpxWaVsusuL4x9ZKWFAU55SNpiRaIS3/agvuiof/p/9IZ3K65ZXTZ8VtEKMqyBB8J8 3HAbDrTzLbx87AFuZn1HWEeQ6pW73D8XMdrvPBfhza+CwLfMfmCwYVNaxM5DCqBS15C1 VbxA==
X-Gm-Message-State: AOUpUlGrENXViKTF/jYXAcHP1c6MV67+ZDbAcWLwz7rY1XZUIAsjTXrJ ImAR5mlOVC2fOeXCCVV3ezyuEwV11+xREGOPX5sKcw==
X-Google-Smtp-Source: AA+uWPxNJEs85jUw4WmjtTMfEg+76AW2vAyEQydW1ecp6YXmyeaq5q0gj8gHi6TCNSzCUzVWEnPzJb5hBN/rmGVFc4Y=
X-Received: by 2002:a0c:f94e:: with SMTP id i14-v6mr20919139qvo.73.1534291260323; Tue, 14 Aug 2018 17:01:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 17:00:59 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Tom Herbert <>
Date: Tue, 14 Aug 2018 17:00:59 -0700
Message-ID: <>
To: Brian E Carpenter <>
Cc: int-area <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-02.txt
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Aug 2018 00:01:07 -0000

On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter
<> wrote:
> Updated following comments received at IETF102.
> -------- Forwarded Message --------
> Subject: I-D Action: draft-carpenter-limited-domains-02.txt
> Date: Mon, 13 Aug 2018 18:42:27 -0700
> From:
> Reply-To:
> To:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>         Title           : Limited Domains and Internet Protocols
>         Authors         : Brian Carpenter
>                           Bing Liu
>         Filename        : draft-carpenter-limited-domains-02.txt
>         Pages           : 15
>         Date            : 2018-08-13
> Abstract:
>    There is a noticeable trend towards network requirements, behaviours
>    and semantics that are specific to a limited region of the Internet
>    and a particular set of requirements.  Policies, default parameters,
>    the options supported, the style of network management and security
>    requirements may vary.  This document reviews examples of such
>    limited domains and emerging solutions.  It shows the needs for a
>    precise definition of a limited domain boundary and for a
>    corresponding protocol to allow nodes to discover where such a
>    boundary exists.
Hi Brian, thanks for the draft.

A couple general points:

* It's unclear to me what it means for a protocol to only work in a
limited domain. I think there is a big difference between describing
how a standard protocol _could_ be deployed in a limited domain for
good effect, versus defining a standard protocol that can _only_
operate correctly in a limited domain. Most of the examples in section
4 are describing deployment of protocols seem to fall in the first
category where protocol deployment might only be feasible in limited
domain, but the definition of the protocol does not require a limited
domain. For instance, the fact that extension headers is not
deployable by the Internet, but may work in a limited domain, is
happenstance on how things evolved. It was never the intent of
extension headers to only be used in limited domains, neither do I
believe there is value in respecifying extension headers as such (I
still believe problems that prevent use on the Internet should be
fixed). On the other hand, something like extension header insertion
would require a protocol to be specified to only work in a limited
domain since that would otherwise break some fundamental requirements
of IPv6.

* If we accept that protocols can be defined for use only limited
domains, what becomes of the priniciple of interoperability? Does this
open up the possibility that "limited domain" could mean that any
possible variant of a protocol is allowed per the "local policy" of
the domain? A limited domain would make anything possible in
protocols. For instance, someone could decide to switch the soure and
destination addresses in IP headers in a limited domain as a local
policy. As long as the requirements of a limited domain is enforced
this is completely feasible (note a limited domain could be defined by
an island in the network having only one vendor solution). So then
does a limited domain become a vehicle for vendors to define and
deploy their own value-add protocol extensions without regard to
interoperability? The open endedness of "local policy" alluded to in
the SR protocol draft as well as some statement concerning the use of
network slices by mobile operators that are run by a single hardware
vendor are noteworthy.,


> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or
> _______________________________________________
> Int-area mailing list