Re: [lisp] Confirm/Deny changes on draft 6830bis

Dino Farinacci <> Fri, 12 January 2018 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1970512AF83 for <>; Fri, 12 Jan 2018 11:01:28 -0800 (PST)
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 RCwmOE2dnz2C for <>; Fri, 12 Jan 2018 11:01:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FC37126D0C for <>; Fri, 12 Jan 2018 11:01:26 -0800 (PST)
Received: by with SMTP id i196so5155281pgd.0 for <>; Fri, 12 Jan 2018 11:01:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FlA1YdBo0XYe41ixCUWEo16DLm5tpRT4HhBJ1zAvOC0=; b=P4WEAz53zMJK6cf7sfvfKwwtvdYWmdpHY5YnPahag4SeJyS5HEE/QTSIswRmBsAUQV W0PARCSh0c7/AZvMl1m4e4sw6O6SUZOcgdBrg3BhRwXO972HMEqZGBWLg6hG/LAXZaG5 d6lQTXK/lEQxQhKF+kIPrq9kc7QaDQWY/Uh3WSXJnruDed/z+oOdByot2tOWNO0a+z1z MvPYzCQbiVX6FmFWVptft5QOcT65KVXPdfv0vEaR3uy1ll2cklFwQiFsO81OOEcfeD+4 oKQhueaf+Go8fvH8Abjg6Xq0v48xPHyhls6e5gY5P1rUytcE05JXVe3xULM/uSEIh3kO rDsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FlA1YdBo0XYe41ixCUWEo16DLm5tpRT4HhBJ1zAvOC0=; b=emuOUs2mY83cBNZZzpTg7i+4DVZI2SEwUoz/6Lgww44bvqv1TeGj/mXVfsYBvzE8yR qFawMZO3/8RZkyhKPojgMqS0mgF6laJ96Po329D/TaY3LQ04FDJCSYMZ43/dD02in0HG E2xPZdAh83lHUWNSLANkz4OwH1TpuWWarO+W0NNgqCiU+5qRXbaasTY4mLLaM+WY67bU 2yL9Jp1rEwSJSHtjopwj64ADa0NnN3fApH/SwtcwuiliTRKiFsu8dfr4JH2F1lCzlber y2z2Fd+JqMyGlGALVq4G74qVTDEfkNUZpNMi77GSWTkY1OQ3Hii4/Ll8ftHj9BAvkYjS ditg==
X-Gm-Message-State: AKwxytenOCW6nzY1ro3MP0SGXbOoXyIqpgGKGAdwkNhR4QcbQjWl2ZXe cU2c+oASetTuPjymNKTymgCVe3YU
X-Google-Smtp-Source: ACJfBovmW5Z+M1jTqcToe4+IDo388KrRKcAxFMTffoVWkZldO1dLqPqF5TGAqFcIW/g+rvybwSyujw==
X-Received: by with SMTP id f3mr9338101pgu.372.1515783685925; Fri, 12 Jan 2018 11:01:25 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id d24sm20677932pfb.30.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 11:01:24 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 12 Jan 2018 11:01:02 -0800
Cc: " list" <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Albert Cabellos <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] Confirm/Deny changes on draft 6830bis
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jan 2018 19:01:28 -0000

> Hi all
> As editor of 6830bis I´d like to confirm or deny the following changes which I believe have support. 

Thanks a lot for doing this Albert. This is very helpful.

> Please note that I have intentionally ignored minor/editorial changes to help sync all the participants. I hope that the list below captures the most relevant ones.
> Also note that I don´t necessarily agree with all the changes listed below, but that´s an opinion with a different hat.

See my brief comments below.

> WG: Please CONFIRM or DENY:

I won’t confirm or deny just yet. I want to hear from other WG members.

> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and ‘identifier of the underlay’ respectively. 

These definitions would be confusing. Because there are multiple identifiers on an overlay. And there are multiple overlays as well. And an instance-ID really defines an overlay. Also, putting the term “identifier” with the underlay would confuse many people. It has been decades where people redefine these terms. It just seems endless and doesn’t improve the situation. And note there isn’t one identifier for an underlay either. One could argue that an underlay VPN could be RLOC space that is different than another underlay VPN. But what identifies that VPN is the mechanism used to realize that VPN and not the RLOCs that use it.

> C.- In section 5.3, change the description of the encap/decap operation concerning how to deal with ECN and DSCP bits to (new text needs to be validated by experts):

These changes are reasonable. I am fine with adding them.