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:[email protected]]
> Envoyé : vendredi 10 mai 2019 09:53
> À : BOUCADAIR Mohamed TGI/OLN; tom petch; Black, David; [email protected]
> Cc : [email protected]; [email protected]; draft-ietf-softwire-
> [email protected]
> 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, [email protected] wrote:
> > Hi Tom,
> >
> > Thanks for sharing your thoughts.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : tom petch [mailto:[email protected]]
> >> Envoyé : jeudi 9 mai 2019 18:13
> >> À : Black, David; BOUCADAIR Mohamed TGI/OLN; [email protected]
> >> Cc : [email protected]; Black, David; [email protected]; draft-ietf-
> softwire-
> >> [email protected]
> >> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> >>
> >> ----- Original Message -----
> >> From: "Black, David" <[email protected]>
> >> 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: [email protected]
> >>>> <[email protected]>
> >>>> Sent: Thursday, May 9, 2019 3:50 AM
> >>>> To: Black, David; [email protected]
> >>>> Cc: [email protected]; [email protected];
> >> [email protected]
> >>>> 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:[email protected]]
> >>>>> Envoyé : mercredi 8 mai 2019 00:46
> >>>>> À : [email protected]
> >>>>> Cc : [email protected]; [email protected]; draft-ietf-softwire-
> >>>>> [email protected]
> >>>>> 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
> >>>>> [email protected] 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
> > [email protected]
> > 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: [email protected]
> ----------------------------------------------------------------------
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
