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

Brian E Carpenter <> Wed, 15 August 2018 05:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BA75130DDD for <>; Tue, 14 Aug 2018 22:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s2xT9EUn2S4n for <>; Tue, 14 Aug 2018 22:26:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 451ED1271FF for <>; Tue, 14 Aug 2018 22:26:52 -0700 (PDT)
Received: by with SMTP id r1-v6so64244pgp.11 for <>; Tue, 14 Aug 2018 22:26:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kSKTKQaKhdzerD0lM8eKoW0L4SyAknjOHz7nDklIxwU=; b=qwixKcoyem4zQn9np1pMhdI8ld7ZXS3pfM533iO7XdMj1VN6aTPjjj1xmKUtK/RfQC q3zswU3jhg+I8JRsOWnniq/tOmPmJ8QrjZw1kxR7Wu7S0BtDhc6hM2hWnUNazn8oJWCo Dys7qLYIm1zD9L7lJWqk+V0S1yImqaDriwHTb1vDZ+9GGXsaLqU6OdC5eVFOA6RDJJAY mJjdtkafXkNqdMrY8w5BNxW305JXjr11oCKj8EyN8+LqoJ8Eu5L+HDmFrz3XEOwk10++ NIZ/ZhWHTy4ID5ozTJk1BdG/otsy0Cgod3SW9nvI2kNg3FQv6M3diCfcdyaOHnJ8amcf DTmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kSKTKQaKhdzerD0lM8eKoW0L4SyAknjOHz7nDklIxwU=; b=dUwwfMr/PbAa6Lz8RcczDNWaa8X8lj5dQx1xu7is7sqY70pVMUFRLBq/QgwAxW4YGi e4MGEEcTx/B0q6wq34J5qn4E0tbVXiSrTflQwe93oVrM18q2WWuBzGNlccutn9qPz0qR mX7daogHcoZCyjDMWCGFaGm7mGRswoZU+eCSP/J4t12Q8rPSFbNQOXzF5wX/qCIW6T6A ZigRJ1JFtp/bpxlMEbgneh/kpmCBmEORbX69qh4HPICIwGtiK8tLdaaTF/nI+6EHq10P O/D1Vpo1kqZ9g3nHOg9sJLwByuInuiU/IqyIMl1cp6k0NVSNMqscAGJt499rHFoDPH2p b2Eg==
X-Gm-Message-State: AOUpUlE9lkC6CxeiE/Oyre3UGl6zThymJC+AU6kowL++rvjvBwNfEWjC odftOgSAy9E/SWJCDqcqbU0=
X-Google-Smtp-Source: AA+uWPwDj7DcmGzj36svdHuUuBye8UuUAX3DXAfJYub2b8G/QY5QzJpevv4w5EOuQsAszh4QT7mkNg==
X-Received: by 2002:a63:5815:: with SMTP id m21-v6mr23187156pgb.78.1534310810947; Tue, 14 Aug 2018 22:26:50 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k64-v6sm41161864pfc.160.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 22:26:49 -0700 (PDT)
To: Tom Herbert <>
Cc: int-area <>, "Liubing (Leo)" <>
References: <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 15 Aug 2018 17:26:50 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 05:26:54 -0000


Thanks for the comments. See in-line:

On 15/08/2018 12:00, Tom Herbert wrote:
> On Mon, Aug 13, 2018 at 7:07 PM, Brian E Carpenter
> 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. 

Agreed. This is exactly why our next step is planned to be
a taxonomy of the various aspects, to try and separate
these issues.

> 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

I'd be very unlikely to do that, personally. But there might be
*semantics* that only apply within a domain. (That is how we
designed diffserv, whereas the original IPv4 TOS design was
supposed to be universal, I believe.)

> still believe problems that prevent use on the Internet should be
> fixed).

I wish that I had confidence that this could be achieved, but
there is an ongoing tension between innovation and firewall rules.

> 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? 

That's a central question. I think the other way of looking at
it is: is it better to recognise that local semantics exist, and
figure out how to contain them, or is it better to simply
say "don't do that"?

> 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.,

Absent protocol police, we can't actually stop people doing such
things, can we? So the question is how can we best deal with the
reality of local semantics without (further) damaging global

Again, thanks, this is very helpful.


> Tom