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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks, Eric & Dave.

 

-- 

Cheers,

Rajiv  

 

From: Eric Vyncke <evyncke@xxxxxxxxx>
Date: Tuesday, May 28, 2019 at 3:07 AM
To: David Black <David.Black@xxxxxxxx>, "tsv-art@xxxxxxxx" <tsv-art@xxxxxxxx>
Cc: Softwires-wg list <softwires@xxxxxxxx>, IETF Discussion <ietf@xxxxxxxx>, "draft-ietf-softwire-iftunnel.all@xxxxxxxx" <draft-ietf-softwire-iftunnel.all@xxxxxxxx>
Subject: Re: Tsvart last call review of draft-ietf-softwire-iftunnel-04

 

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" <noreply@xxxxxxxx> wrote:

 

    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

    tsv-art@xxxxxxxx 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

    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.

    

    

    

 

 


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux