[lisp] Confirm/Deny changes on draft 6830bis

Albert Cabellos <albert.cabellos@gmail.com> Fri, 12 January 2018 16:20 UTC

Return-Path: <albert.cabellos@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE64B12420B for <lisp@ietfa.amsl.com>; Fri, 12 Jan 2018 08:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 suyMF2dFgTVJ for <lisp@ietfa.amsl.com>; Fri, 12 Jan 2018 08:20:41 -0800 (PST)
Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 011BA12D943 for <lisp@ietf.org>; Fri, 12 Jan 2018 08:20:41 -0800 (PST)
Received: by mail-yb0-x232.google.com with SMTP id j7so2908690ybl.3 for <lisp@ietf.org>; Fri, 12 Jan 2018 08:20:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=lusukQn0nZXRRTBUTHBQbp693cl+XBMDEkc4p1Bfzfw=; b=Sn73kliE6+TtS1LJ4Oub/eacwpmAk2R5R10E+eXhhLgyIguPjdVGhFeVl/FLesOckd Hic1ig5wWHIYpfD4RXeYt1tmj//vnJkSLFDzQVbUvY7ZBeIlKO0XvUXDPt82mVUl8M3X eD42B1oStoCti57Cm6ONNXqAbdcw5LHnRJnuQQ31KOs23FXWMEmBJRR0DLACpG9ZbYXP jSCPLx8gVeh5DH4oh7AbayLFSLleNnR9mHKU8N2rGYf5iIjU4HVU87AqgGOx40AMFg8H 7PhtvUKuGEXVOAZN0kvou6H0UgPkvUT2055En1X5QrjezIV+6FdAaNhVhp1yCnCN2KFO fsJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lusukQn0nZXRRTBUTHBQbp693cl+XBMDEkc4p1Bfzfw=; b=fwbcPDc98hDu7os//SRrLc80UsiQDEWUW3WR4u7Pxvvk/B6VysCtXn8UHat7djuPWX C9h8A1T18O1U1jQzRxuvhSKIHeuVOkEUl+T/FDLgpTD/aXkwSkWXC+eMzo4a5Re3g/QN G+7fn9ZDY4Pu+Venfc5ryczykBWiEGyT/qQH4AuManB2sID2msb1H7x/UBkBw7PvCL3A bLp5eb3olOXpmljFC3i6NA0siK1CXDSn24F9GNOwVmWr6cE69tJviw+aJROmzQWW9s+5 uFzFM/XYD/IkxQ800kv5dOKyWSAudtl476V68M8ZkP9Hn82QxnNse2SEIMoV0U7BSGvZ lYwQ==
X-Gm-Message-State: AKGB3mJRbrMGDbFFxM4Oa0YOqVEu0MHLSoP/sYyR/zUPl3TS/AiLeDu+ 9oYPYlB1OH4LCCbAtASTCUlYV42k1lZPqjw7OprpGDrm
X-Google-Smtp-Source: ACJfBosjjGluKqZV7viXzUaGYiDOwVXaWb4J5xAXMFn7nO2C1yS2YNk1npXx9Qy/OCcirsjnvfu9NOtHjmIT/l9OJ9g=
X-Received: by 10.37.131.16 with SMTP id s16mr22203873ybk.129.1515774039932; Fri, 12 Jan 2018 08:20:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.164.38 with HTTP; Fri, 12 Jan 2018 08:20:39 -0800 (PST)
From: Albert Cabellos <albert.cabellos@gmail.com>
Date: Fri, 12 Jan 2018 17:20:39 +0100
Message-ID: <CAGE_Qex--1pS5ivDmSZXVXLsFRgO+a9F32YmJL_dO7h4+4QMCA@mail.gmail.com>
To: "lisp@ietf.org list" <lisp@ietf.org>
Cc: Dino Farinacci <farinacci@gmail.com>, lisp-chairs@tools.ietf.org
Content-Type: multipart/alternative; boundary="089e0832e26035c4b1056296a5a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/wg0mdUKNrpK8ZZR-AUxdcwSjcOk>
Subject: [lisp] Confirm/Deny changes on draft 6830bis
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jan 2018 16:20:43 -0000

Hi all

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

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.

WG: Please CONFIRM or DENY:

-------

A.- Remove definitions of PA and PI

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

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):

When doing ITR/PITR encapsulation:

o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case
of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.

o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy
the 2-bit 'ECN' field from the inner header to the outer header.
Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer
header to the new outer header.

When doing ETR/PETR decapsulation:

 o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the
case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field,
when the Time to Live value of the outer header is less than the Time to
Live value of the inner header.  Failing to perform this check can cause
the Time to Live of the inner header to increment across
encapsulation/decapsulation cycles.  This check is also performed when
doing initial encapsulation, when a packet comes to an ITR or PITR destined
for a LISP site.

o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. If the 'ECN' field contains
a congestion indication codepoint (the value is '11', the Congestion
Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the surviving inner header
that is used to forward the packet beyond the ETR.  These requirements
preserve CE indications when a packet that uses ECN traverses a LISP tunnel
and becomes marked with a CE indication due to congestion between the
tunnel endpoints.

Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate
after decapsulating, the net effect of this is that the new outer header
will carry the same Time to Live as the old outer header minus 1.

Copying the Time to Live (TTL) serves two purposes: first, it preserves the
distance the host intended the packet to travel; second, and more
importantly, it provides for suppression of looping packets in the event
there is a loop of concatenated tunnels due to misconfiguration.  See
Section 18.3 for TTL exception handling for traceroute packets.


D.- Simplify section ‘Router Locator Selection’ stating that the data-plane
MUST follow what´s stored in the map-cache (priorities and weights), the
remaining text should go to an OAM document.

E.- Rewrite Section “Routing Locator Reachability” considering the
following changes:

*    Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and
Echo-Nonce
*    Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3
(hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a
response) and RLOC probing



F.- Move Solicit-Map-Request to 6833bis

G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document