RE: registering tunnel types

<mohamed.boucadair@orange.com> Mon, 29 October 2018 14:20 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63E8130F56 for <ipv6@ietfa.amsl.com>; Mon, 29 Oct 2018 07:20:50 -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 x4Vh63233PlK for <ipv6@ietfa.amsl.com>; Mon, 29 Oct 2018 07:20:49 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A650F130F4D for <ipv6@ietf.org>; Mon, 29 Oct 2018 07:20:48 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 42kGwb36Lnz201f; Mon, 29 Oct 2018 15:20:47 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 42kGwb2364zDq7j; Mon, 29 Oct 2018 15:20:47 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0415.000; Mon, 29 Oct 2018 15:20:47 +0100
From: mohamed.boucadair@orange.com
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: registering tunnel types
Thread-Topic: registering tunnel types
Thread-Index: AQHUb4+v3pddy6JmC0mFtn2awh6dnaU2QhRw
Date: Mon, 29 Oct 2018 14:20:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302E03A0F5@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <01a901d46bb2$26c23700$4001a8c0@gateway.2wire.net> <e1ebf233-6e34-8d78-3ce3-293602462665@gmail.com> <787AE7BB302AE849A7480A190F8B93302E039F88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <e71cbb98-a841-013c-1baa-300c45db20bd@gmail.com>
In-Reply-To: <e71cbb98-a841-013c-1baa-300c45db20bd@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/29GYiPH4OUVK7h5SJJagpDv3VXc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2018 14:20:51 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
> Envoyé : lundi 29 octobre 2018 15:00
> À : BOUCADAIR Mohamed TGI/OLN; ipv6@ietf.org
> Objet : Re: registering tunnel types
> 
> 
> 
> Le 29/10/2018 à 13:19, mohamed.boucadair@orange.com a écrit :
> > Alex,
> >
> > draft-ietf-softwire-yang relies on an existing registry: :
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-6.
> So, the list cited by Tom is from that registry. draft-ietf-softwire-yang is
> only echoing those values.
> 
> It's a long list in section titled:
> "Internet-standard MIB - mib-2.interface.ifTable.ifEntry.ifType.tunnelType"
> 

[Med] The current registry includes 17 values.  

> I think it binds the concept of a 'tunnel' to that of an 'interface'.
> 
> They are distinct.  Not only there are interfaces that are not tunnels
> but there are tunnels that have no interfaces either.  (i.e. tunnels
> that are not visible in the full list of interfaces of a computer).

[Med] If you have any concern with the design, you can raise the point to the authors of RFC4087, RFC8343, and RFC7224.

> 
> This boils down to the YANG model to _not_ see these tunnels either.

[Med] RFC8343 allows to indicate the type of an interface. Supported values are defined in RFC7224. In particular, the type of an interface can be "tunnel". Because tunnel interfaces can be different types, new identities echoing "tunnelType" are derived from "ift:tunnel".  

> 
> Alex
> 
> >
> > If you need a new value or if you have a question about a given interface
> tunnel type, please follow the guidelines in the url cited above. All this is
> out of the scope of draft-ietf-softwire-yang.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Alexandre Petrescu
> >> Envoyé : jeudi 25 octobre 2018 09:54
> >> À : ipv6@ietf.org
> >> Objet : Re: registering tunnel types
> >>
> >> Are:
> >> -IPv6 in UDPv4 and
> >> -IPv6 in IPv6 as used by openvpn;
> >>
> >> covered by the list below?
> >>
> >> These are a few tunnelling mechanisms I use routinely.
> >>
> >> Existing identity 6tofour should be deprecated, if that means 6to4,
> >> which is deprecated.
> >>
> >> Existing identity iphttps has a version number for IP?
> >>
> >> Alex
> >>
> >> Le 24/10/2018 à 17:57, tom petch a écrit :
> >>> draft-ietf-softwire-yang
> >>> completed IETF Last Call two weeks ago and, since then, has acquired a
> >>> YANG module that defines tunnel types, as listed below.  It is intended
> >>> to be a IANA-maintained module and so changes to the list of tunnels
> >>> will not require a reissue of the softwires RFC-to-be.  At the same
> >>> time, getting it right first time never did any harm so if anyone can
> >>> think of any missing, or can think of other places where there might be
> >>> other tunnels lurking, now would be a good time to mention it.
> >>>
> >>> It is based on RFC4087 Tunnel MIB (which created an SMI Textual
> >>> Convention that went up to Teredo) so tunnels from that vintage are
> >>> likely well catered for.  softwires is not where I would have first
> >>> looked for tunnel types, but it has a certain logic to it.
> >>>
> >>>        identity  other
> >>>
> >>>        identity direct
> >>>
> >>>        identity gre
> >>>
> >>>        identity minimal
> >>>
> >>>        identity l2tp
> >>>
> >>>        identity pptp
> >>>
> >>>        identity l2f
> >>>
> >>>        identity udp
> >>>
> >>>        identity atmp
> >>>
> >>>        identity msdp
> >>>
> >>>        identity sixtofour
> >>>
> >>>        identity sixoverfour
> >>>
> >>>        identity isatap
> >>>
> >>>        identity teredo
> >>>
> >>>        identity iphttps
> >>>
> >>>        identity softwiremesh
> >>>
> >>>        identity dslite
> >>>
> >>>        identity  aplusp
> >>>
> >>> Tom Petch
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------