Re: [Softwires] [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04

<mohamed.boucadair@orange.com> Fri, 10 May 2019 08:51 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB53C1201C9; Fri, 10 May 2019 01:51:03 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 SvuvjrSDUn9N; Fri, 10 May 2019 01:51:01 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAA81201C3; Fri, 10 May 2019 01:51:00 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 450kSz1gkvz8tTK; Fri, 10 May 2019 10:50:59 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 450kSz0mTtz1xpC; Fri, 10 May 2019 10:50:59 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 10 May 2019 10:50:58 +0200
From: <mohamed.boucadair@orange.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "softwires@ietf.org" <softwires@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-softwire-iftunnel.all@ietf.org" <draft-ietf-softwire-iftunnel.all@ietf.org>, tom petch <daedulus@btconnect.com>, "Black, David" <David.Black@dell.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
Thread-Topic: [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04
Thread-Index: AQHVBjvrk/E3tsg9nUazN7srpiDCQqZkAoTA
Date: Fri, 10 May 2019 08:50:58 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA7B7B0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <155726915148.24435.7582686501694078061@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA7A76F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CE03DB3D7B45C245BCA0D243277949363055C97D@MX307CL04.corp.emc.com> <01be01d50681$86da50e0$4001a8c0@gateway.2wire.net> <787AE7BB302AE849A7480A190F8B93302EA7B682@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <HE1PR0701MB25220ED34E8B3D826C34EF02950C0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB25220ED34E8B3D826C34EF02950C0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/OZfY7HmiovBvX5Ppj1rSl5pKO6c>
Subject: Re: [Softwires] [Tsv-art] Tsvart last call review of draft-ietf-softwire-iftunnel-04
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 May 2019 08:51:04 -0000

Hi Magnus,

The context and the need for draft-ietf-softwire-iftunnel are indicated in the write-up:

"During the publication process and IANA review of draft-ietf-
softwire-yang (which has been approved by IESG recently), IANA 
requested that the YANG module for the iana-iftunnel registry
was put into a separate document from softwire-yang.
draft-ietf-softwire-iftunnel was published containing just 
the module."

draft-ietf-softwire-yang is in the RFC editor queue with a normative dependency on draft-ietf-softwire-iftunnel.

Below some excerpts from the I-D to answer your other questions:

Scope: 
   ====== 
   This document specifies the initial version of the iana-tunnel-type
   YANG module containing a collection of IANA maintained YANG
   identities identifying tunnel interface types.  The module reflects
   IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY].  

      Tunnel type values must not be directly added to the iana-tunnel-
      type YANG module.  They must instead be respectively added to the
      "tunnelType" sub-registry (under the "ifType definitions"
      registry).

      When this registry is modified, the YANG module iana-tunnel-type
      must be updated as defined in RFCXXXX.
   ======

Out of Scope:
   ======
   It is not the intention of this document to
   define tunnel-specific extensions for every tunnel encapsulation
   technology; those are discussed in dedicated documents such as
   [I-D.ietf-softwire-yang].  Likewise, it is out of the scope of this
   document to update the existing IANA registry   
   [TUNNELTYPE-IANA-REGISTRY] with a comprehensive list of tunnel
   technologies.
   ======

How it can be used? 
   ======
   Tunnel-specific extensions may be added to the Interface module
   [RFC8343] as a function of the tunnel type.  An example of this is
   provided in Appendix A.
   ======

   e.g., if I want to define a GRE YANG module, I need to import the module defined in draft-ietf-softwire-iftunnel:  

     import iana-tunnel-type  {
       prefix iana-tunnel-type;
     }

   And then indicate the following to augment the Interface module with GRE specifics: 

     augment "/if:interfaces/if:interface" {
       when "derived-from(if:type, 'iana-tunnel-type:gre')";

Cheers,
Med

> -----Message d'origine-----
> De : Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Envoyé : vendredi 10 mai 2019 09:53
> À : BOUCADAIR Mohamed TGI/OLN; tom petch; Black, David; tsv-art@ietf.org
> Cc : softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire-
> iftunnel.all@ietf.org
> Objet : Re: [Tsv-art] Tsvart last call review of draft-ietf-softwire-
> iftunnel-04
> 
> Hi,
> 
> Based on Tom's comment about the issues or discrepancies in purpose, I
> would like to request that the purpose of the iftunnel document is made
> clear at least in a email response. As not being active and being thrown
> under the bus of having to do an IESG review of this document it would
> be really good if you could provide some summary of the context and the
> need for this particular document. Especially in light of how it uses
> the IANA registry.
> 
> Thanks
> 
> Magnus Westerlund
> 
> 
> On 2019-05-10 08:20, mohamed.boucadair@orange.com wrote:
> > Hi Tom,
> >
> > Thanks for sharing your thoughts.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : tom petch [mailto:daedulus@btconnect.com]
> >> Envoyé : jeudi 9 mai 2019 18:13
> >> À : Black, David; BOUCADAIR Mohamed TGI/OLN; tsv-art@ietf.org
> >> Cc : softwires@ietf.org; Black, David; ietf@ietf.org; draft-ietf-
> softwire-
> >> iftunnel.all@ietf.org
> >> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> >>
> >> ----- Original Message -----
> >> From: "Black, David" <David.Black@dell.com>;
> >> Sent: Thursday, May 09, 2019 2:45 PM
> >>
> >>>> [Med] The intent of the draft is to reflect the current registered
> >> tunnels types.
> >>> ...
> >>>> [Med] Registering new tunnel types is not in the scope set for this
> >> draft.
> >>> I understand that, but as stated in the review, I don't think that
> >> it's the best course of action.  The email below appears to reject all
> >> of the IETF Last Call comments in the review and in particular presents
> >> the scope of the draft as fixed and unchangeable; that's unfortunate.
> >> On that basis, I will agree to disagree and leave these IETF Last Call
> >> concerns to the ADs to sort out.
> >> David
> >>
> >> I think that the concerns that you raise need addressing.
> > [Med] It is an easy fix to update the draft with a table asking codes
> for the following example list:
> >
> >    o  CAPWAP [RFC5415]
> >    o  AMT [RFC7450]
> >    o  TCP Encapsulation of IKE and IPsec Packets [RFC8229]
> >    o  NSH [RFC8300]
> >    o  VXLAN [RFC7348]
> >    o  LISP [RFC6830bis]
> >    o  VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe]
> >    o  Geneve [I-D.ietf-nvo3-geneve]
> >    o  GUE [I-D.ietf-intarea-gue]
> >
> > but I'm struggling with the rationale for doing this in draft-ietf-
> softwire-iftunnel.
> >
> > Can you please help me understand the following:
> >
> > * Why such request wasn't made earlier for the following?
> >
> >    o  CAPWAP [RFC5415]
> >    o  AMT [RFC7450]
> >    o  TCP Encapsulation of IKE and IPsec Packets [RFC8229]
> >    o  NSH [RFC8300]
> >    o  VXLAN [RFC7348]
> >
> > * Why working in progress specifications can't make this request
> directly to IANA if such code is needed?
> >
> >    o  LISP [RFC6830bis]
> >    o  VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe]
> >    o  Geneve [I-D.ietf-nvo3-geneve]
> >    o  GUE [I-D.ietf-intarea-gue]
> >
> > * What is the point in having a codepoint but no actual usage is defined
> for it?
> >
> >
> > I also think
> >> that there is another consideration that might be of greater impact.
> >>
> >> The definition of interface types has long been an IANA registry which
> >> has been incorporated into MIB modules and, latterly, YANG modules.
> >> Recently, there has been an I-D
> >> Guidelines and Registration Procedures for Interface Types
> >> with Authors : David Thaler   Dan Romascanu
> >> which, if I read it aright, is saying that the process has gone off the
> >> rails and that the IANA registry should be of Interface Types and
> >> nothing to do with MIB modules or YANG modules, although the YANG and
> >> MIB modules will most likely be derived from it.  I see it as a
> question
> >> of who owns the registry, and that it should be those concerned with
> >> interfaces and their specification and that those concerned with OAM
> >> should take second place to that.
> >>
> >> If that logic is correct, then I would apply it to tunnels, that the
> >> registration of tunnels belongs to those concerned with tunnels,
> >> int-area perhaps, where I see drafts on tunnels being discussed, with
> >> those concerned with OAM building on that work but not being the
> >> drivers, controllers, thereof.
> >>
> >> Tom Petch
> >>
> >>> Thanks, --David
> >>>
> >>>> -----Original Message-----
> >>>> From: mohamed.boucadair@orange.com
> >>>> <mohamed.boucadair@orange.com>;
> >>>> Sent: Thursday, May 9, 2019 3:50 AM
> >>>> To: Black, David; tsv-art@ietf.org
> >>>> Cc: softwires@ietf.org; ietf@ietf.org;
> >> draft-ietf-softwire-iftunnel.all@ietf.org
> >>>> Subject: RE: Tsvart last call review of
> >> draft-ietf-softwire-iftunnel-04
> >>>>
> >>>> [EXTERNAL EMAIL]
> >>>>
> >>>> Hi David,
> >>>>
> >>>> Thank you for the review.
> >>>>
> >>>> Please see inline.
> >>>>
> >>>> Cheers,
> >>>> Med
> >>>>
> >>>>> -----Message d'origine-----
> >>>>> De : David Black via Datatracker [mailto:noreply@ietf.org]
> >>>>> Envoyé : mercredi 8 mai 2019 00:46
> >>>>> À : tsv-art@ietf.org
> >>>>> Cc : softwires@ietf.org; ietf@ietf.org; draft-ietf-softwire-
> >>>>> iftunnel.all@ietf.org
> >>>>> Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> >>>>>
> >>>>> Reviewer: David Black
> >>>>> Review result: Not Ready
> >>>>>
> >>>>> This document has been reviewed as part of the transport area
> >> review
> >>>> team's
> >>>>> ongoing effort to review key IETF documents. These comments were
> >>>> written
> >>>>> primarily for the transport area directors, but are copied to the
> >> document's
> >>>>> authors and WG to allow them to address any issues raised and also
> >> to the
> >>>>> IETF discussion list for information.
> >>>>>
> >>>>> When done at the time of IETF Last Call, the authors should
> >> consider this
> >>>>> review as part of the last-call comments they receive. Please
> >> always CC
> >>>>> tsv-art@ietf.org if you reply to or forward this review.
> >>>>>
> >>>>> This draft defines a YANG module for tunnel types based on the
> >> MIB-2
> >>>>> tunnel type registry maintained by IANA.
> >>>>>
> >>>>> My fundamental concern with this draft is that the MIB-2 tunnel
> >> type
> >>>>> registry is seriously incomplete and out of date, as there are a
> >> large
> >>>>> number of tunnel types that aren't included in that registry,
> >> e.g., IPsec
> >>>>> tunnel-mode AMT tunneling.  In its current form, that registry
> >> does not
> >>>>> appear to be a good starting point for specifying YANG management
> >> of
> >>>>> tunnels.
> >>>>>
> >>>>> A limited justification that I could envision for defining this
> >> YANG module
> >>>>> would be to use it for mechanical translations to YANG of existing
> >> MIBs
> >>>>> that use MIB-2 tunnel types - if that's the justification, then it
> >> would need
> >>>>> to be clearly stated in an applicability statement within this
> >> draft,
> >>>> [Med] The intent of the draft is to reflect the current registered
> >> tunnels
> >>>> types. This is mentioned in the introduction:
> >>>>
> >>>>    This document specifies the initial version of the
> >> iana-tunnel-type
> >>>>                                ^^^^^^^^^^^^^^
> >>>>    YANG module identifying tunnel interface types.  The module
> >> reflects
> >> ^^^^^^^^
> >>>>    IANA's registry maintained at [TUNNELTYPE-IANA-REGISTRY].  The
> >> latest
> >>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>>    revision of this module can be obtained from the IANA web site.
> >>>>
> >>>>  and the
> >>>>> discussion of extension of this YANG module would need to be
> >> aligned
> >>>> with
> >>>>> that limited applicability.
> >>>> [Med] This is an IANA-maintained module. That is, when a new tunnel
> >> type is
> >>>> registered, the module will be automatically updated to include that
> >> new
> >>>> type identity:
> >>>>
> >>>>       When this registry is modified, the YANG module
> >> iana-tunnel-type
> >>>>       must be updated as defined in RFCXXXX.
> >>>>
> >>>>> The proverbial "right thing to do" would be to update both the
> >> MIB-2
> >>>> tunnel
> >>>>> type registry and this draft with all of the currently known
> >> tunnel types.
> >>>> [Med] Registering new tunnel types is not in the scope set for this
> >> draft. It is
> >>>> up to the documents defining these tunnel types or making use of
> >> them to
> >>>> make a request to IANA. For example, this is the approach followed
> >> in
> >>>> softwire wg for at least three tunnel types (16, 17, 18).
> >>>>
> >>>>> The references section of draft-ietf-tsvwg-rfc6040update-shim
> >>>>>
> >> (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/)
> >>>>> may help in identifying tunnel protocols that should be included.
> >>>>>
> >>>>> A minor concern involves the use of RFC 8085 as the reference for
> >> UDP
> >>>>> tunnels; while that's certainly better than the existing use of
> >> RFC 4087, due
> >>>>> to the extensive design guidance in RFC 8085, designers of UDP-
> >>>> encapsulated
> >>>>> tunnel protocols ought to be encouraged to register their
> >> protocols as
> >>>>> separate
> >>>>> tunnel types (e.g., so the network operator has some idea of what
> >> the UDP
> >>>>> tunnel is actually being used for).  This draft ought to encourage
> >> tunnel
> >>>>> protocol designers to register their own tunnel types in
> >> preference to
> >>>> reuse
> >>>>> of the UDP tunnel type, including placing text in the IANA tunnel
> >> type
> >>>>> registry and this YANG module to encourage that course of action.
> >>>>>
> >>>> [Med] Wouldn't that recommendation be better added to documents such
> >>>> as: https://tools.ietf.org/html/draft-thaler-iftype-reg-02?
> > _______________________________________________
> > Tsv-art mailing list
> > Tsv-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/tsv-art
> >
> 
> --
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------