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

From: Dong Jiang <[email-masked]>
Date: Thu, 19 Nov 2015 10:34:11 +0200

Dear Carlos,

We have modified the draft and plan to update a new version recently. Here
are the details based on your comments:

1. We have added RFC 5512 and RFC 5566 in Terminology.

2. In section 5.1 we have mentioned that Softwire mesh framework RFC 5565
[RFC5565] does not mandate the use of any particular tunneling technology.
Based on the BGP tunnel encapsulation attribute tunnel types introduced by
RFC 5512[RFC5512] and RFC 5566[RFC5566], the softwire mesh tunnel types
include at least L2TPv3 over IP, GRE, Transmit tunnel endpoint, IPsec in
Tunnel mode, IP in IP tunnel with IPsec Transport Mode, MPLS-in-IP tunnel
with IPsec Transport Mode and IP in IP.

Since swmSupportedTunnelTable is used to provide the information about what
kind of tunnel can be used for softwire mesh, we do not plan to manage
detailed TLV information of each established tunnel in
swmSupportedTunnelTable.

3. We have removed the sentence of ‘The swmMIB module can be used for
configuration of certain objects,’ in Security Consideration.

4. We have added RFC 5566 and RFC 5640 in Normative References.

Thank you!

Br,
Jiang

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

> 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.
>
> 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 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: Dong Jiang <[email-masked]>
Date: Thu, 19 Nov 2015 10:58:47 +0200

Dear Deng Hui,

1. We have added quotation mark for 0.0.0.0 and ::

2. We have added references for swmEncapsEIPDst and swmEncapsIIPDst.

3. We have explained the usage of ipv4(1) and ipv6(2) in different scenario
in the DESCRIPTION of swmEncapsEIPDstType:

“This object specifies the address type used for swmEncapsEIPDst. It is
different from the tunnelIfAddressType in the tunnelIfTable. The
swmEncapsEIPDstType is IPv6 (2) if it is IPv6-over-IPv4 tunneling. The
swmEncapsEIPDstType is IPv4 (1) if it is IPv4-over-IPv6 tunneling.”

We also added "IPv4 and IPv6 in RFC RFC4001." in REFERECNCE:

4. swmEncapsEIPDstType and swmEncapsIIPDstType are using two different
address types in the scenario of softwire mesh. For example, if
swmEncapsEIPDstType is ipv4, swmEncapsIIPDstType will be IPv6. Thus we did
not modify this part.

5. We have modified the DESCRIPTION: "Represents the tunnel type that can
be used for softwire mesh scenario, such as L2TPv3 over IP, GRE, Transmit
tunnel endpoint, IPsec in Tunnel-mode, IP in IP tunnel with IPsec Transport
Mode, MPLS-in-IP tunnel with IPsec Transport Mode and IP in IP. There is no
restriction of tunnel type the Softwire mesh can use."

6. The number of connection tunnels can be calculated by the number of
entries in swmEncapsTable. Thus we did not add new statistic object. But we
clarified this in 5.2: “The number of entries in swmEncapsTable shows how
many softwire mesh tunnels are maintained in this AFBR.”

7. Since swmEncapsIIPDst is an ip address used for encapsulation, the
prefix length is the length of the ip address. Thus we did not define
swmEncapsIIPDstPrefixLength.

8. swmEncapsEIPDst and swmEncapsIIPType are not-accessible since they are
used for indexing (section7.7 of RFC1902 says Objects which are both
specified in the INDEX clause of a conceptual row and also columnar objects
of the same conceptual row are termed auxiliary objects.  The MAX-ACCESS
clause for auxiliary objects is "not-accessible").

Thank you!

Best regards,

Jiang

2015-10-25 9:55 GMT+02:00 Hui Deng <[email-masked]>:

> Hi
> 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
> Please find below review comments:
>
> 1) Page 5 in section 6.2, “The tunnelIfRemoteInetAddress MUST be set to
> 0.0.0.0 for IPv4 or :: for IPv6 because it is a point to multi-point
> tunnel.”
> It needs quotation mark for 0.0.0.0 and ::
>
> 2) In the MIB definitions, it needs REFERENCE for the IMPORT objects. eg:
> swmEncapsEIPDst OBJECT-TYPE
> SYNTAX InetAddress
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "The E-IP destination prefix, which is
> used for I-IP encapsulation destination looking up."
> ::= { swmEncapsEntry 2 }
>
> It should add a REFERENCE “E-IP and I-IP in RFC 5565 ”. The same comment
> for the definition of swmEncapsIIPDst.
>
> 3) In page 8,
> swmEncapsEIPDstType OBJECT-TYPE
> SYNTAX InetAddressType
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This object specifies the address type used for
> swmEncapsEIPDst. It is different from the tunnelIfAddressType
> in the tunnelIfTable."
> ::= { swmEncapsEntry 1 }
>
> It should list ipv4(1) and ipv6(2) in the DESCRIPTION for different
> scenario. Also it should add a REFERENCE to RFC 4001.
>
> 4) In page 8, SwmEncapsEntry: I think swmEncapsEIPDstType and
> swmEncapsIIPDstType should just be swmEncapsIPDstType and apply to both. If
> all address objects in
>
> the row are of the same type, you only need one type object.
>
> 5) In page 7, “Represents the tunnel type that the AFBR supports” in
> definition of swmSupportedTunnelType. It need a clarification that It
> represents the tunnel
>
> type used for softwire mesh scenario.
>
> 6) As it states in the section 6.1, the ifInucastPkts counts the number
> of IPv6 packets which are sent to the virtual interface for decapsulation
> into IPv4. I
>
> think it need some statistics objects to define for the softwire mesh such
> as the number of the connection tunnel when running point to multi-point
> tunnel.
>
> 7) Why not define a parameter for swmEncapsIIPDstPrefixLength?
>
> 8) In the swmEncapsGroup, there are only information about
> swmEncapsIIPDst and swmEncapsIIPDstType, why there are not swmEncapsEIPDst
> and swmEncapsIIPType and so on?
>
> Best regards,
>
> DENG Hui
>