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

[<[e-mail]>]

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:[e-mail]]
> Envoyé : vendredi 10 mai 2019 09:53
> À : BOUCADAIR Mohamed TGI/OLN; tom petch; Black, David; [e-mail]
> Cc : [e-mail]; [e-mail]; draft-ietf-softwire-
> [e-mail]
> 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, [e-mail] wrote:
> > Hi Tom,
> >
> > Thanks for sharing your thoughts.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : tom petch [mailto:[e-mail]]
> >> Envoyé : jeudi 9 mai 2019 18:13
> >> À : Black, David; BOUCADAIR Mohamed TGI/OLN; [e-mail]
> >> Cc : [e-mail]; Black, David; [e-mail]; draft-ietf-
> softwire-
> >> [e-mail]
> >> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> >>
> >> ----- Original Message -----
> >> From: "Black, David" <[e-mail]>
> >> 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: [e-mail]
> >>>> <[e-mail]>
> >>>> Sent: Thursday, May 9, 2019 3:50 AM
> >>>> To: Black, David; [e-mail]
> >>>> Cc: [e-mail]; [e-mail];
> >> [e-mail]
> >>>> 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:[e-mail]]
> >>>>> Envoyé : mercredi 8 mai 2019 00:46
> >>>>> À : [e-mail]
> >>>>> Cc : [e-mail]; [e-mail]; draft-ietf-softwire-
> >>>>> [e-mail]
> >>>>> 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
> >>>>> [e-mail] 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art
> >
> 
> --
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------