Subject: Tsvart last call review of draft-ietf-softwire-iftunnel-04

From: David Black via Datatracker <[email-masked]>
Date: Tue, 07 May 2019 15:45:51 -0700

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-masked] 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, and the
discussion of extension of this YANG module would need to be aligned with
that limited applicability. 

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 8 May 2019 20:36:05 +0000

Hi David,

Thanks for your review and comments. QQ -

>tunnel-mode AMT tunneling.

Do you happen to have the list of missing MIB-2 tunnel types?

--
Cheers,
Rajiv

From: David Black via Datatracker <[email-masked]>
Reply-To: David Black <[email-masked]>
Date: Tuesday, May 7, 2019 at 6:46 PM
To: "[email-masked]" <[email-masked]>
Cc: Softwires-wg list <[email-masked]>, IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Resent-From: <[email-masked]>
Resent-To: "[email-masked]" <[email-masked]>, <[email-masked]>, Rajiv Asati <[email-masked]>, Yong Cui <[email-masked]>, Eric Vyncke <[email-masked]>, <[email-masked]>, Yong Cui <[email-masked]>
Resent-Date: Tuesday, May 7, 2019 at 6:45 PM

Reviewer: David Black
Review result: Not Ready

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-masked]<mailto:[email-masked]> if you reply to or forward this review.

---

From: "Black, David" <[email-masked]>
Date: Wed, 8 May 2019 20:41:06 +0000

As noted in the review:

Thanks, --David

From: Rajiv Asati (rajiva) <[email-masked]>
Sent: Wednesday, May 8, 2019 4:36 PM
To: Black, David; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04

[EXTERNAL EMAIL]
Hi David,

--
Cheers,
Rajiv

From: David Black via Datatracker <[email-masked]<mailto:[email-masked]>>
Reply-To: David Black <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 7, 2019 at 6:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Softwires-wg list <[email-masked]<mailto:[email-masked]>>, IETF Discussion <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Tsvart last call review of draft-ietf-softwire-iftunnel-04
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Rajiv Asati <[email-masked]<mailto:[email-masked]>>, Yong Cui <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Yong Cui <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, May 7, 2019 at 6:45 PM

Reviewer: David Black
Review result: Not Ready

---

From: <[email-masked]>
Date: Thu, 9 May 2019 07:49:50 +0000

Hi David, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : David Black via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 8 mai 2019 00:46
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; draft-ietf-softwire-
> [email-masked]
> Objet : Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> Reviewer: David Black
> Review result: Not Ready
> 
> 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
> 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.

> 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).  

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

---

From: "Black, David" <[email-masked]>
Date: Thu, 9 May 2019 13:45:53 +0000

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

Thanks, --David

> -----Original Message-----
> From: [email-masked]
> <[email-masked]>
> Sent: Thursday, May 9, 2019 3:50 AM
> Subject: RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi David,
> 
> [Med] The intent of the draft is to reflect the current registered tunnels
> types. This is mentioned in the introduction:
> 
> [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:
> 
> [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).
> 
> [Med] Wouldn't that recommendation be better added to documents such
> as: https://tools.ietf.org/html/draft-thaler-iftype-reg-02?

---

From: <[email-masked]>
Date: Thu, 9 May 2019 14:43:11 +0000

Re-,

I agree with you that many tunneling schemes are not present in the IANA registry but is that a problem? I don't think so because registrations are for a reason. 

The natural way from where I sit is that any specification that, for example, defines a specific YANG module for a tunneling scheme not currently in the IANA registry, and needs a specific interface type, will make a request for a code assignment.

FWIW, we are making this work because we had a concrete case (draft-ietf-softwire-yang) which needs to augment the YANG interface module for a specific tunnel scheme. To that aim, we requested IANA to assign a new type and designed this module to access to tunnel types maintained by IANA.

When a new registration is made, the module defined in draft-ietf-softwire-iftunnel will be updated automatically by IANA.  

I fail to see why the "best course of action" for this document is to register new types without defining the usage.  

Cheers,
Med

> De : Black, David [mailto:[email-masked]]
> Envoyé : jeudi 9 mai 2019 15:46
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> [email-masked]; Black, David
> Objet : RE: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> 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.
> 
> Thanks, --David
>

---

From: tom petch <[email-masked]>
Date: Thu, 9 May 2019 16:12:44 +0000

----- Original Message -----
From: "Black, David" <[email-masked]>
Sent: Thursday, May 09, 2019 2:45 PM

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

> > Cc: [email-masked]; [email-masked];
[email-masked]
> > > This document has been reviewed as part of the transport area
review
> > team's
^^^^^^^^
> > > discussion of extension of this YANG module would need to be
aligned
> > with
> > > The proverbial "right thing to do" would be to update both the
MIB-2
> > tunnel
> > > tunnel protocols ought to be encouraged to register their
protocols as
> > > separate
> > > protocol designers to register their own tunnel types in
preference to
> > reuse

---

From: <[email-masked]>
Date: Fri, 10 May 2019 06:20:12 +0000

Hi Tom,

Thanks for sharing your thoughts. 

Please see inline. 

Cheers,
Med

> De : tom petch [mailto:[email-masked]]
> Envoyé : jeudi 9 mai 2019 18:13
> À : Black, David; BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Cc : [email-masked]; Black, David; [email-masked]; draft-ietf-softwire-
> [email-masked]
> Objet : Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04
> 
> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 10 May 2019 07:52:48 +0000

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-masked] wrote:
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> 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-masked]
----------------------------------------------------------------------

---

From: <[email-masked]>
Date: Fri, 10 May 2019 08:50:58 +0000

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).

   ======

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

> De : Magnus Westerlund [mailto:[email-masked]]
> Envoyé : vendredi 10 mai 2019 09:53
> À : BOUCADAIR Mohamed TGI/OLN; tom petch; Black, David; [email-masked]
> Objet : Re: [Tsv-art] Tsvart last call review of draft-ietf-softwire-
> iftunnel-04
> 
> Hi,
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 17 May 2019 15:29:07 +0000

Dan and David, I took the liberty to add you to the discussion as draft-thaler-iftype-reg could be a way forward.

David, thank you for your review and the raised point.

Tom, and Magnus, thank you as well for being part of the discussion.

David, I see your point about referring to an 'outdated hence invalid' reference. I think we all agree that we need to have a IANA registry of ifTypes per draft-thaler-iftype-reg. 

Nevertheless, I do not want to delay this document until that registry is created by the IANA as at least one other document depends on this one. Furthermore, I am unsure about the will of Dave & Dan to push forward their I-D.

Med, can you have a -06 revision with:
- clearer abstract (basically  copy & paste of the 1st paragraph of the introduction) with the specific limitations / restrictions pointed by the reviews (for example "... containing the limited and incomplete collection of IANA...")
- what about adding some text about "Upon the create of a IANA registry of ifType, then an update of this document will be required". Unsure whether it has ever been used in a RFC though.

But, at least fix the abstract and be more restrictive on the 'value' of the current ifType MIB

Hope this will allow the document to progress

-éric

    ...

    Thanks, --David

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 17 May 2019 15:31:06 +0000

Hi Éric,
  Just responding to one point.

> On May 17, 2019, at 11:29 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 

They have brought this document to intarea and I offered to AD sponsor it for them. I will get the process kicked off in the next few days for this.

Thanks
Suresh

---

From: <[email-masked]>
Date: Mon, 20 May 2019 07:39:19 +0000

Hi Eric, all,

Please see inline. 

Cheers,
Med

> De : Eric Vyncke (evyncke) [mailto:[email-masked]]
> Envoyé : vendredi 17 mai 2019 17:29
> [email-masked]; [email-masked]
> Dan and David, I took the liberty to add you to the discussion as draft-
> thaler-iftype-reg could be a way forward.
> 
> David, I see your point about referring to an 'outdated hence invalid'
> reference. I think we all agree that we need to have a IANA registry of
> ifTypes per draft-thaler-iftype-reg.
> 
> Nevertheless, I do not want to delay this document until that registry is
> created by the IANA as at least one other document depends on this one.

[Med] draft-thaler-iftype-reg does not create any new registry.

> Furthermore, I am unsure about the will of Dave & Dan to push forward
> their I-D.
> 
> - clearer abstract (basically  copy & paste of the 1st paragraph of the
> introduction) with the specific limitations / restrictions pointed by the
> reviews (for example "... containing the limited and incomplete collection
> of IANA...")

[Med] I can update the abstract as follows: 

OLD: 
   This document specifies a YANG module containing a collection of IANA
   maintained YANG identities, used as interface types for tunnel
   interfaces.

NEW:
   This document specifies the initial version of a YANG module
   containing a collection of IANA maintained YANG identities, used as
   interface types for tunnel interfaces.  The module reflects the
   "ifType definitions: tunnelType" registry maintained by IANA.  The
   latest revision of this module can be obtained from the IANA web
   site.

> - what about adding some text about "Upon the create of a IANA registry of
> ifType, then an update of this document will be required". Unsure whether
> it has ever been used in a RFC though.

[Med] I'm not sure about this one. As mentioned above, there is no current plan to create another yet iftype registry.

If the point is how the module will be updated if new entries are registered? Then, this is not a concern because the module is maintained by IANA; that is, any change to the register will be systematically reflected by IANA in the IANA module.

For example, registration requests for new tunnel types can made following the rules in draft-thaler-iftype-reg. Once granted, the iftunnel module be updated by IANA following the rules defined in draft-ietf-softwire-iftunnel. No RFC update is required. 

> 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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 28 May 2019 07:07:31 +0000

Dear all,

Thank you again for the review.

After discussion with Dave Thaler (who maintains the tunnel type IANA registry), it appears that the draft can go forward without waiting for a complete IANA registry for tunnel types.

Best regards

-éric

On 08/05/2019, 00:45, "David Black via Datatracker" <[email-masked]> wrote:

    Reviewer: David Black
    Review result: Not Ready

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 29 May 2019 18:46:07 +0200

Hi Eric,

Just catching up on this thread now. And indeed, thanks for the review, David. Just to complete my understanding of the situation, can you briefly explain what the plan for updating the tunnel type registry is then?

Mirja

> On 28. May 2019, at 09:07, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Dear all,
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 29 May 2019 19:05:55 +0000

Thanks, Eric & Dave.

--
Cheers,
Rajiv

From: Eric Vyncke <[email-masked]>
Date: Tuesday, May 28, 2019 at 3:07 AM
To: David Black <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Softwires-wg list <[email-masked]>, IETF Discussion <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04

Dear all,

Best regards

-éric

On 08/05/2019, 00:45, "David Black via Datatracker" <[email-masked]<mailto:[email-masked]>> wrote:

    Reviewer: David Black
    Review result: Not Ready