Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04

"BRUNGARD, DEBORAH A" <db3546@att.com> Wed, 15 August 2018 18:30 UTC

Return-Path: <db3546@att.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 63BBF131093; Wed, 15 Aug 2018 11:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 25r8sBG7LL74; Wed, 15 Aug 2018 11:30:30 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AB8130E89; Wed, 15 Aug 2018 11:30:30 -0700 (PDT)
Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7FIFUOL037208; Wed, 15 Aug 2018 14:24:58 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2kvrya17me-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Aug 2018 14:24:58 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7FIOuuj019725; Wed, 15 Aug 2018 14:24:57 -0400
Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7FIOsJ0019707; Wed, 15 Aug 2018 14:24:54 -0400
Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 3F6DA40397D4; Wed, 15 Aug 2018 18:24:54 +0000 (GMT)
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (unknown [130.9.129.151]) by zlp27129.vci.att.com (Service) with ESMTPS id 1BE63400041E; Wed, 15 Aug 2018 18:24:54 +0000 (GMT)
Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.41]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0408.000; Wed, 15 Aug 2018 14:24:53 -0400
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: Fabio Maino <fmaino@cisco.com>, Adrian Farrel <adrian@olddog.co.uk>
CC: "lisp@ietf.org" <lisp@ietf.org>, "draft-ietf-lisp-gpe.all@ietf.org" <draft-ietf-lisp-gpe.all@ietf.org>
Thread-Topic: Rtgdir last call review of draft-ietf-lisp-gpe-04
Thread-Index: AQHUL/rptGnvayTge0qYxHM0x66st6TBau6A//++k2A=
Date: Wed, 15 Aug 2018 18:24:53 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C8883CD51D@MISOUT7MSGUSRDE.ITServices.sbc.com>
References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com>
In-Reply-To: <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.16.234.232]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-15_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808150189
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/GzetuMkW4-Kj_wlB93LU6kHFygM>
Subject: Re: [lisp] Rtgdir last call review of draft-ietf-lisp-gpe-04
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 15 Aug 2018 18:30:40 -0000

Hi Fabio,

Yes, please update-
Deborah


-----Original Message-----
From: Fabio Maino <fmaino@cisco.com> 
Sent: Wednesday, August 15, 2018 2:15 PM
To: Adrian Farrel <adrian@olddog.co.uk>uk>; rtg-dir@ietf.org
Cc: lisp@ietf.org; ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org
Subject: Re: Rtgdir last call review of draft-ietf-lisp-gpe-04

Hi Adrian,
thanks for such a detailed review.

I went through your comments and I can incorporate all of them into a new version of the draft.

Wrt the reduction in size of the Map-Versioning and Nonce fields, I could add in Section 3, right after the definition of the encoding of those fields, the following:

> The encoding of the Nonce field in LISP-GPE, compared with the one 
> used in RFC6830bis for the LISP data plane encapsulation, reduces the 
> length of the nonce from 24 to 16 bits. As per RFC6830bis, ITRs are 
> required to generate different nonces when sending to different RLOCs, 
> but the same nonce can be used for a period of time when encapsulating 
> to the same ETR. The use of 16 bits nonces still allows  an ITR to 
> determine to and from reachability for up to 64k RLOCs at the same time.
>
> Similarly, the encoding of the Source and Dest Map-Version fields, 
> compared with RFC6830bis, is reduced from 12 to 8 bits. This still 
> allows to associate 256 different versions to each EID-to-RLOC mapping 
> to inform commmunicating ITRs and ETRs about modifications of the 
> mapping.
>


Either Deborah, Joel, or Luigi: if you could please confirm that it is ok to publish a new version of the draft at this point, I'll update it right away.

Thanks,
Fabio




On 8/9/18 9:05 AM, Adrian Farrel wrote:
> Reviewer: Adrian Farrel
> Review result: Has Issues
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this 
> draft. The Routing Directorate seeks to review all routing or 
> routing-related drafts as they pass through IETF last call and IESG 
> review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs.
> For more information about the Routing Directorate, please see 
> ?https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.o
> rg_area_rtg_trac_wiki_RtgDir&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGp
> W9lwi9dM7jYlxXD8w&m=PkWde6zu-kE9gzGQsc-9pYLwdcRrjIa2425Q4AJA-fg&s=_8An
> SBg0ZBNU-n2uz9kLjT6VwSTXHys-h_54ayvz9PA&e=
>
> Although these comments are primarily for the use of the Routing ADs, 
> it would be helpful if you could consider them as normal review 
> comments. I believe that this review comes between WG publication and 
> the start of IETF last call - you may wish to discuss with your AD 
> whether to treat these comments separately or as part of IETF last call.
>
> Document: draft-ietf-lisp-gpe-04.txt
>   Reviewer: Adrian Farrel
>   Review Date: 9-August-2018
>   IETF LC End Date: No known
>   Intended Status: Standards Track
>
> Summary
> I have significant concerns about this document and recommend that the 
> Routing ADs discuss these issues further with the authors. The issues 
> are not substantially technical in nature, but do indicate the need 
> for significant reworking of the text. I have tried to make suggestions for new text.
>
> Comments:
>
> This document specifies an alternate LISP header format that can be 
> used to allow LISP to carry payloads other than IP. A new capabilities 
> flag is defined so that routers know whether this new format is 
> supported, and a new flag in the header itself indicates when the new format is in use.
>
> The document is clear and readable, but has some issues of 
> presentation that could close a few potential misunderstandings and 
> thus improve implmentation prospects.
>
> No attempt is made in the document to explain how/why the reduction in 
> size of some standard LISP header fields is acceptable. For example, 
> if implementations of this spec can safely operate with a 16 bit Nonce 
> or 8 bit Map-Versions, why does 6830/6830bis feel the need for 24 and 12 bit fields rspectively?
>
> ===Major Issues===
>
> Section 3 has a mix of minor and leess minor issues...
>
> OLD
>     This document defines the following changes to the LISP header in
>     order to support multi-protocol encapsulation:
>
>     P Bit:  Flag bit 5 is defined as the Next Protocol bit.  The P bit
>        MUST be set to 1 to indicate the presence of the 8 bit next
>        protocol field.
>
>        P = 0 indicates that the payload MUST conform to LISP as defined
>        in [I-D.ietf-lisp-rfc6830bis].  Flag bit 5 was chosen as the P bit
>        because this flag bit is currently unallocated.
>
>     Next Protocol:  The lower 8 bits of the first 32-bit word are used to
>        carry a Next Protocol.  This Next Protocol field contains the
>        protocol of the encapsulated payload packet.
>
>        LISP uses the lower 24 bits of the first word for either a nonce,
>        an echo-nonce, or to support map-versioning
>        [I-D.ietf-lisp-6834bis].  These are all optional capabilities that
>        are indicated in the LISP header by setting the N, E, and the V
>        bit respectively.
>
>        When the P-bit and the N-bit are set to 1, the Nonce field is the
>        middle 16 bits.
>
>        When the P-bit and the V-bit are set to 1, the Version field is
>        the middle 16 bits.
>
>        When the P-bit is set to 1 and the N-bit and the V-bit are both 0,
>        the middle 16-bits are set to 0.
>
>        This document defines the following Next Protocol values:
>
>        0x1 :  IPv4
>
>        0x2 :  IPv6
>
>        0x3 :  Ethernet
>
>        0x4 :  Network Service Header [RFC8300]
>
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |N|L|E|V|I|P|K|K|        Nonce/Map-Version      | Next Protocol |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                 Instance ID/Locator-Status-Bits               |
>         
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                                LISP-GPE Header
>
> NOTES
>     - It would be helpful to put the figure higher up
>     - The use of "MUST" for the P-bit is attenuated wrongly
>     - Need to be consistent on "P Bit" or "P-bit" or "P bit"
>     - There looks to be a problem in the case of map version. The base
>       spec has 12 bits each for source and dest map-version, so this doc
>       needs to describe how the reeduced 16 bits is split (presumably not
>       12 and 4).
>     - You need a pointer to the IANA registry for next protocol NEW
>     This document defines two changes to the LISP header in order to
>     support multi-protocol encapsulation: the introduction of the P-bit
>     and the definition of a Next Protocol field.  This is shown in
>     Figure 1 and described below.
>
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |N|L|E|V|I|P|K|K|        Nonce/Map-Version      | Next Protocol |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                 Instance ID/Locator-Status-Bits               |
>         
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                           Figure 1 : The LISP-GPE Header
>
>     P-Bit:  Flag bit 5 is defined as the Next Protocol bit.
>
>        If the P-bit is clear (0) the LISP header conforms to the
>        definition in [I-D.ietf-lisp-rfc6830bis].
>
>        The P-bit is set to 1 to indicate the presence of the 8 bit Next
>        Protocol field.
>
>     Next Protocol:  The lower 8 bits of the first 32-bit word are used to
>        carry a Next Protocol.  This Next Protocol field contains the
>        protocol of the encapsulated payload packet.
>
>        In [I-D.ietf-lisp-6834bis], LISP uses the lower 24 bits of the
>        first word for a nonce, an echo-nonce, or to support map-
>        versioning.  These are all optional capabilities that are
>        indicated in the LISP header by setting the N, E, and V bits
>        respectively.
>
>        When the P-bit and the N-bit are set to 1, the Nonce field is the
>        middle 16 bits (i.e., encoded in 16 bits, not 24 bits).  Note that
>        the E-bit only has meaning when the N-bit is set.
>
>        When the P-bit and the V-bit are set to 1, the Version fields use
>        the middle 16 bits: the Source Map-Version uses the high-order 8
>        bits, and the Dest Map-Version uses the low-order 8 bits.
>
>        When the P-bit is set to 1 and the N-bit and the V-bit are both 0,
>        the middle 16-bits MUST be set to 0 on transmission and ignored on
>        receipt.
>
>        This document defines the following Next Protocol values:
>
>        0x1 :  IPv4
>
>        0x2 :  IPv6
>
>        0x3 :  Ethernet
>
>        0x4 :  Network Service Header [RFC8300]
>
>        The values are tracked in an IANA registry as described in Section
>        5.
>
> ---
>
> Section 4 must describe the error case when a LISP-GPE capable router 
> sets the P-bit on a packet to a non LISP-GPE capable router. So...
>
> OLD
>     When encapsulating IP packets to a non LISP-GPE capable router the P
>     bit MUST be set to 0.
> NEW
>     When encapsulating IP packets to a non LISP-GPE capable router the P-
>     bit MUST be set to 0.  That is, the encapsulation format defined in
>     this document MUST NOT be sent to a router that has not indicated
>     that it supports this specification because such a router would
>     ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so
>     would misinterpret the other LISP header fields possibly causing
>     significant errors.
> END
>
> ---
>
> 4.1
>
> Not your fault that RFC 8060 doesn't have a registry for bits in the 
> LCAF, but now you really need one or else future orthogonal specs risk 
> colliding with the g-bit.  A bit odd to add this in this document, but 
> not worth a bis on 8060.
>
> ===Minor Issues ===
>
> Section 2
>
> OLD
>     The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags
>     (some defined, some reserved), a Nonce/Map-version field and an
>     instance ID/Locator-status-bit field.  The flags provide flexibility
>     to define how the various fields are encoded.  Notably, Flag bit 5 is
>     the last reserved bit in the LISP header.
>
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |                 Instance ID/Locator-Status-Bits               |
>         
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                                  LISP Header NOTES
>     We need to be careful not to risk any confusion. At least, "some
>     reserved" is an over-statement. But also we should not show a repeat
>     of the Lisp header as that causes a duplicate definition.
> NEW
>     The LISP header is defined in [I-D.ietf-lisp-rfc6830bis] and contains
>     a series of flags of which one (bit 5) is shown in that document as
>     "reserved for future use".  The setting of the flag fields defined
>     how the subsequent header fields are interpretted.
> END
>
> ---
>
> 4.1
> I don't think you should reproduce the Multiple Data-Planes LCAF Type 
> figue from 8060 here as it creates a duplicate definition.  The text 
> explanation of which bit is the g-bit shold be enough.
>
> ===Nits===
>
> Abstract
> OLD
>     This document describes extending the Locator/ID Separation Protocol
>     (LISP) Data-Plane, via changes to the LISP header, to support multi-
>     protocol encapsulation.
> NEW
>     This document describes extentions to the Locator/ID Separation
>     Protocol (LISP) Data-Plane, via changes to the LISP header, to
>     support multi-protocol encapsulation.
> END
>
> ---
>
> 1.
> OLD
>     LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines
>     an encapsulation format that carries IPv4 or IPv6 (henceforth
>     referred to as IP) packets in a LISP header and outer UDP/IP
>     transport.
> NEW
>     The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis].  It
>     specifies an encapsulation format that carries IPv4 or IPv6 packets
>     (henceforth jointly referred to as IP) in a LISP header and outer
>     UDP/IP transport.
>
> ---
>
> 1.1
> Please use the new boilerplate...
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>     "OPTIONAL" in this document are to be interpreted as described in BCP
>     14 [RFC2119] [RFC8174] when, and only when, they appear in all
>     capitals, as shown here.
>
> ---
>
> 1.2
> Nothwithstanding the text in this section, abbreviations need to be 
> expanded either on first use or in this section.
> I see:
> - LCAF
> - ETR
> - ITR
> - RLOC
> - xTR
>
> ---
>
> 2.
> s/As described in the introduction/As described in Section 1/ s/LISP 
> is limited to carry IP payloads/LISP is limited to carrying IP 
> payloads/
>
> ---
>
> 4.1
> s/field as g bit/field as the g-bit/
>
> ---
>
> 8.1
> Please add RFC 8174
>