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

[<[e-mail]>]

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?
> >