Re: registering tunnel types

[Alexandre Petrescu <[e-mail]>]

Le 29/10/2018 à 15:20, [e-mail] a écrit :
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Alexandre Petrescu [mailto:[e-mail]]
>> Envoyé : lundi 29 octobre 2018 15:00
>> À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
>> Objet : Re: registering tunnel types
>>
>>
>>
>> Le 29/10/2018 à 13:19, [e-mail] 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.

Thank you for the redirection to authors of 3 RFCs :-)

I do not have a concern with the design.

Alex

> 
>>
>> 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:[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
>>>> --------------------------------------------------------------------