Subject: [Int-dir] Int-Dir - Review of draft-ietf-softwire-mesh-mib-11

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 22 Oct 2015 19:00:55 +0000

Hi,

I am an assigned INT directorate reviewer for draft-ietf-softwire-mesh-mib-11. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/directorate/intarea.html <http://www.ietf.org/iesg/directorate/intarea.html>.

This document defines MIB objects to manage softwire mesh solutions, and targets the Standards Track.

I have a number of comments and concerns with this document, which amount to requesting the ADs to take a closer look:

3.  Terminology

   This document uses terminology from the softwire problem statement
   RFC 4925 [RFC4925] and the softwire mesh framework RFC 5565
   [RFC5565].

CMP: I think terminology from RFC 5512 is also heavily used.

5.1.  The swmSupportedTunnelTable Subtree

   According
   to section 4 of RFC 5512 [RFC5512], current softwire mesh tunnel
   types include IP-IP, GRE and L2TPv3.

CMP: This is true, but at the same time there are now many other “current tunnel types” (which are actually BGP Tunnel Encapsulation Attribute Tunnel Types). See http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types <http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types> Specifically the ones introduced by RFC5566 ought to be included.

CMP: This comment also applies to swmSupportedTunnelType

XX. Missing sub-TLVs

CMP: If the Tunnel Type is one which requires encapsulation information (e.g., L2TPv3 Session ID, Cookie, GRE Key, etc.), how is that information managed? I cannot seem to find it in the MIB Module. See Section 4.1 of RFC 5512.

CMP: Similarly, what about Protocol Type and Color (S4.2 and 4.3 of RFC 5512), and IPsec Tunnel Authenticator (RFC 5566)?

CMP: Similarly, what about the Load-Balancing Block values from RFC 5640? Without this, an ECMP-aware L2TPv3 tunnel will be misunderstood.

8.  Security Considerations

   The swmMIB module can be used for configuration of certain objects,

CMP: How is this so, without read-write or read-create?

11.  References

11.1.  Normative References

CMP: Curiously, I do not see RFC 5566 or RFC 5640 referenced.

Hope these help!

Thanks,

— Carlos.

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 25 Oct 2015 04:08:53 +0000

Thanks for your review Carlos. Authors, can you please respond to this review.

Regards
Suresh

On 10/22/2015 03:01 PM, Carlos Pignataro (cpignata) wrote:
> Hi,
>
> I am an assigned INT directorate reviewer for
> draft-ietf-softwire-mesh-mib-11. These comments were written primarily for
> the benefit of the Internet Area Directors. Document editors and shepherd(s)
> should treat these comments just like they would treat comments from any
> other IETF contributors and resolve them along with any other Last Call
> comments that have been received. For more details on the INT
> Directorate, see http://www.ietf.org/iesg/directorate/intarea.html.
>
> I have a number of comments and concerns with this document, which amount to
> requesting the ADs to take a closer look:
>
> 3.  Terminology
>
> CMP: This is true, but at the same time there are now many other “current
> tunnel types” (which are actually BGP Tunnel Encapsulation Attribute Tunnel
> Types). See
> http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types Specifically
> the ones introduced by RFC5566 ought to be included.
>
> CMP: If the Tunnel Type is one which requires encapsulation information
> (e.g., L2TPv3 Session ID, Cookie, GRE Key, etc.), how is that information
> managed? I cannot seem to find it in the MIB Module. See Section 4.1 of RFC 5512.
>
> CMP: Similarly, what about Protocol Type and Color (S4.2 and 4.3 of RFC
> 5512), and IPsec Tunnel Authenticator (RFC 5566)?
>
> CMP: Similarly, what about the Load-Balancing Block values from RFC 5640?
> Without this, an ECMP-aware L2TPv3 tunnel will be misunderstood.
>

---

From: Dong Jiang <[email-masked]>
Date: Sun, 25 Oct 2015 10:26:45 +0200

Dear Carlos,

Thank you for the comments! We'll revise the draft accordingly.

Best regards,
Jiang

2015-10-22 22:00 GMT+03:00 Carlos Pignataro (cpignata) <[email-masked]>:

> the benefit of the Internet Area Directors. Document editors and
> shepherd(s) should treat these comments just like they would treat comments
> from any other IETF contributors and resolve them along with any other Last
> Call comments that have been received. For more details on the INT
> I have a number of comments and concerns with this document, which amount
> to requesting the ADs to take a closer look:
>
> 3.  Terminology
>