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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 15 August 2018 18:30 UTC

Return-Path: <adrian@olddog.co.uk>
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 6EA7613108C; Wed, 15 Aug 2018 11:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Q9-R3GHYus25; Wed, 15 Aug 2018 11:30:27 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 B65F9130DF6; Wed, 15 Aug 2018 11:30:26 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id w7FIULUV017726; Wed, 15 Aug 2018 19:30:21 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 593F222042; Wed, 15 Aug 2018 19:30:21 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 400C92204A; Wed, 15 Aug 2018 19:30:21 +0100 (BST)
Received: from 950129200 (229.91.112.87.dyn.plus.net [87.112.91.229]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w7FIUIdj006521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2018 19:30:19 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Fabio Maino'" <fmaino@cisco.com>, <rtg-dir@ietf.org>
Cc: <lisp@ietf.org>, <ietf@ietf.org>, <draft-ietf-lisp-gpe.all@ietf.org>
References: <153383075580.28970.16196543565444262922@ietfa.amsl.com> <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com>
In-Reply-To: <1c15b23d-abe7-16c5-d7d8-88279b061441@cisco.com>
Date: Wed, 15 Aug 2018 19:30:18 +0100
Message-ID: <015201d434c6$05902a10$10b07e30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGrV/OofqTlg1gMRiMR5UDgCNFOBgHrrPAlpQN9NOA=
Content-Language: en-gb
X-Originating-IP: 87.112.91.229
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24034.002
X-TM-AS-Result: No--35.829-10.0-31-10
X-imss-scan-details: No--35.829-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24034.002
X-TMASE-Result: 10--35.828700-10.000000
X-TMASE-MatchedRID: yebcs53SkkAZax9TsUmzyeYAh37ZsBDCt3aeg7g/usAutoY2UtFqGFdV hcU0C7v4RV3Jvwv5IomxJZlbR4Xa9lrzSUKT6RlXma6DzXaohvPDHSNFHFxB883WsuqkgrPjyms yD5ZDYiKkzut+vhJOLUz/oFwO7+N+W/Dpe0fsrIpCnGIuUMP0VVAI6wCVrE3vDzHdHAreOMVlmv qsqaAYaxfEMA1zsy4OJUrYO+8+T/CrzuBPuFwqQk0jzafXv7tTYQXxsZnRwoJrKNt7ipQiYxEag Ylxo94PVgVZDJENjzI5pv/p79MF1dXXXs1Z8vkC8OsWh3diggrUZrYvzuo9ArrfxlRjqBJ3FhMg ncTYqyRkcD2Pk3/H3tl/84vVNSajq0LcAkhU1lF8Uw4r8ep8Bn+vzHfC29pfpMEnsw8ssa6kQu0 /M/TLDkIiCGakGnQ9x5ikrsSuxdbLIr1irshnclVCBNP48QP9NACnndLvXwfb6Y+fnTZUL33398 wxgdEB/esbbEiRiTnb3DJ2e4GMIpnPexZXV5z5kRs1fAcYNHGhfX5oAjRY3pTx+2LIqNmtjNETH H9N9TZeCaDw/ofFOyyMYZ1O/+1WsbrrpvzFsu8SS5pQAyYxiu4dka7CjortMKZRiezcUtNZc6Pc 0imoinyFbrfLM824xOwqJ2xqFVHEFB+Bmr71qu78M8+rjHgCviRliDV2nywCB9odk/ZD8DjsVNj k91jAj4P46izEGRMskUg+WjIazOF7Pq0ToovmlUgQqGVMqmyP/EshoNKyEUK7eJQWtfQOxURYSO EGU3tp0u+4Heb9WT63/DOLFD0VYY3ozW+EngeeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/8fpRUZG9D9QsKWC5OHfmBoFq8kw>
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:38 -0000

Hi Fabio,

That additional text is helpful, thanks.

Adrian

> -----Original Message-----
> From: Fabio Maino [mailto:fmaino@cisco.com]
> Sent: 15 August 2018 19:15
> To: Adrian Farrel; 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
> > ?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > 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
> >