Re: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review

Tom Herbert <> Tue, 19 May 2015 21:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6725B1A1EF7 for <>; Tue, 19 May 2015 14:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.578
X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IS6d0qteEvr7 for <>; Tue, 19 May 2015 14:45:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1EFE1A1C03 for <>; Tue, 19 May 2015 14:45:54 -0700 (PDT)
Received: by iebgx4 with SMTP id gx4so24927743ieb.0 for <>; Tue, 19 May 2015 14:45:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1efeFOxREYvDgFYi2e2o+8ODyTPY/PwH2H4zzEYhEL8=; b=mTzuxTlb9lpko5oX8XMhbWGDohGL30/72NisTbKI4pN0yU36NtFFUaEfpQrrAu1gsy QjZSTxKDDpYlHo1Ie7wqs6sv76Uala9dRlrNcWvzrIR4N4Jtcx20PzfOUM/humGoOIBC UPkn/T971bmLa7aJoOxVWUyEptQaIxSUp5A5Pqt3JtvNHuit79Q9zm9lVTO3iIXOabXq 2DMnXolYEgBbxldd6ydTheq9oz4J6Di4ke9XhIUxGAguLgvFojRU9Egqk8pNewtjkzC9 D+ltBmBJWU3+HboH5wHJQ5u/oy9AF06lOT8Rn0f7RrHrftYJtpC7PZxr/wPJ68ZVJXu2 H6Cw==
X-Gm-Message-State: ALoCoQnSI0hV6WGpG/zwpnP7p0EZmttE4Nxij23mC+d+o6RL/lHJq0SADqJXtvnKAJFqFC7XkB56
MIME-Version: 1.0
X-Received: by with SMTP id br7mr30951099icc.43.1432071954014; Tue, 19 May 2015 14:45:54 -0700 (PDT)
Received: by with HTTP; Tue, 19 May 2015 14:45:53 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 19 May 2015 14:45:53 -0700
Message-ID: <>
From: Tom Herbert <>
To: Erik Nordmark <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [Rtg-dt-encap-considerations] draft-rtg-dt-encap-02 for review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Design Team on Encapsulation Considerations discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2015 21:45:56 -0000

Some comments on version 02:

On the IPv6 flow label: Brian Carpenter made pretty much the same
point that IPv6 flow label could be used in lieu of UDP encapsulation
for entropy. This was in the context of IP-over-UDP. The argument was
short circuited a bit because IP-over-UDP lacked extensibility and we
already have N other protocols that can do the same thing but are
extensible. It might be worthwhile to point out that a major reason
for encapsulating over UDP is that it allows arbitrary and extensible
encapsulations, entropy for ECMP is essentially nice side effect.


In relationship to encapsulating in UDP it seems like DTLS will be
preferred over IPsec (e.g. GRE/UDP)  in this context as being a better
fit. In this simplest form this seems to means that UDP encap
protocols will be asking for two port assignments.

"Interaction with packet security such as IPsec" -> "Interaction with
packet security such as IPsec or DTLS"

I would rewrite 2nd paragraph is section 11.3 as:

"The more interesting case is when security is applied to the
encapsulation payload. This will keep the encapsulation headers in the
outer header visible to the network (for instance in nvo3 we may way
to firewall based on VNI ID even if the payload is encrypted). On
possibility is to apply DTLS to the encapsulation payload. In this
model the protocol stack may be something like
IP|UDP|Encap|DTLS|encrypted_payload. The encapsulation and security
should be done together at an encapsulator and resolved at the
decapsulator. Since the encapsulation header is outside of the
security coverage, this may itself require security (like described

In last paragraph of section 11.3 please scratch whole sentence "In
this case of security..."

Section 13:

Unnecessary colloquialism? "encaps"->"encapsulation method"

I think section 15.1 can be removed

Section 18:

Would change "Avoid full packet checksums in encapsulation if
possible" to "Avoid full packet checksums in cases where necessary
devices cannot support them"

"if" -> "If" in same paragraph

Section 22 Open issues, next protocol header. Joe Touch has been
arguing that IPv4 and IPv6 should not use separate protocol numbers by
the same one as IP encapsulation and differentiate by IP version
number. Don't know if we want to bring this up, but someone eventually
will. :-)


On Thu, May 14, 2015 at 11:00 AM, Erik Nordmark <> wrote:
> Attached is -02 of the document.
> Albert said he would check whether there are some additional text we want to
> add about the control word, but I've completed the other edits we have
> discussed.
> is up to date with the issues, but doesn't have the exact same proposed text
> changes as the I-D.
> I edited the attached diffs to remove the diffs related to the change in
> pagination.
> Please review the changes, and check whether there are additional things we
> should lift out to the "In summary" bulleted lists.
> It would be good to submit this next week - if anything controversial shows
> up we can discuss it on the call next Thursday.
> Regards,
>    Erik
> _______________________________________________
> Rtg-dt-encap-considerations mailing list