Re: registering tunnel types

[tom petch <[e-mail]>]

---- Original Message -----
From: "Joel Jaeggli" <[e-mail]>
To: "tom petch" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; "Alexandre
Petrescu" <[e-mail]>
Sent: Tuesday, October 30, 2018 8:23 PM

> On Oct 30, 2018, at 05:07, tom petch <[e-mail]> wrote:
>>
>
> Alex
>
> I agree, at least in part; tunnels and interfaces are different
animals
> and it is unfortunate that they were conflated in SMI.
>
> I was surprised that NETMOD had not produced a YANG module for tunnels
> but it seems that there has been no need for the past decade.  That
> said, I think that it is a good idea to have one.  Whether or not it
> should mirror the Tunnel MIB I find more debatable.

It’s not entirely obvious to me that netted / netconfig would be where
the tunnel models were produced.

They tend if fact to be produced by the tunnel protocol maintainers e.g.
l3sm/l2sm/ccamp and so on. The management tools for a product tend to be
developed itself in my experience.

<tp>

Joel

My concern is that something that cuts across a number of IETF WG should
get adequate review.  The YANG interface module was much discussed in
the netmod WG, with an existing MIB as guidance, before becoming an RFC.

The proposed YANG tunnel module, which borrows the concepts of the
interface module, that additions should be made by the Tunnel MIB
Designated Expert to a registry and then propagated to the Tunnel MIB
and the Tunnel YANG module, has not been discussed in any WG.  The
proposal, as I mentioned before, has been added to the I-D after IETF
Last Call has been completed so appears to me to be the work of one
individual, without any review; the I-D lists seven editors, six of whom
appear to be absent.  TheWG mailing list seems devoid of any discussion.

I believe that the IETF succeeds because of peer review, and I struggle
to see that here.

Tom Petch

> My own homework came across other IP in IP varieties which do not
> appear.
>
> Tom Petch
>
>
>>
>> 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:[e-mail]] De la part de Alexandre
> Petrescu
>>>> Envoyé : jeudi 25 octobre 2018 09:54
>>>> À : [e-mail]
>>>> 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
>>>>> [e-mail]
>>>>> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
>>
>>>> -------------------------------------------------------------------
-
>>>>>
>>>>
>>
>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail] <mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------