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

<mohamed.boucadair@orange.com> Fri, 10 May 2019 06:20 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 4407712017F; Thu, 9 May 2019 23:20:18 -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 ZrTU1aDaOQ9i; Thu, 9 May 2019 23:20:15 -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 18C8E120169; Thu, 9 May 2019 23:20:15 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 450g711YNNzBsFJ; Fri, 10 May 2019 08:20:13 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 450g7101Zhz1xpY; Fri, 10 May 2019 08:20:13 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([fe80::d9:d3cd:85bd:d331%21]) with mapi id 14.03.0439.000; Fri, 10 May 2019 08:20:12 +0200
From: <mohamed.boucadair@orange.com>
To: tom petch <daedulus@btconnect.com>, "Black, David" <David.Black@dell.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "softwires@ietf.org" <softwires@ietf.org>, "Black, David" <David.Black@dell.com>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-softwire-iftunnel.all@ietf.org" <draft-ietf-softwire-iftunnel.all@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Thread-Index: AQHVBoIIoGotpmycT0al8kNJQOcXkqZj3ojg
Date: Fri, 10 May 2019 06:20:12 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA7B682@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>
In-Reply-To: <01be01d50681$86da50e0$4001a8c0@gateway.2wire.net>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/rnogmp_QAeuk2o3p0oCjgnZkhC8>
Subject: Re: [Softwires] 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 06:20:18 -0000

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?
> >