Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07

["Fuyu (Eleven)" <[e-mail]>]

Hi Tom,

Thank you for your review and comments.

The main difference for the NAT management between the NATv2-MIB and DSLite-MIB is that the NATv2-MIB describe the tunnel information on the view of address level. But the DSLite-MIB define it on the view of interface.

I think the NAT objects defined in DSLite-MIB should make in accordance with the tunnel management as the TUNNEL-MIB do.

So do you feel OK if I described the following quoted statement as " The tunnel information defined in NATV2-MIB on the address level for DS-Lite scenario. Because the TUNNEL-MIB defined the objects on the view of interface, the DS-Lite-MIB need defined the tunnel objects to extend the NAT binding entry by interface for accordance."

Best Regards

Yu


-----Original Message-----
From: Tom Taylor [mailto:[e-mail]] 
Sent: Monday, March 16, 2015 8:30 AM
To: Yong Cui; Fuyu (Eleven)
Cc: [e-mail] WG; Krishnan Suresh
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07

Sorry to let my review of the updated version slip.

I think the key contribution of this document lies in its tunnel management aspect. I'm concerned that the NAT management part still has a considerable overlap with the NATv2-MIB
     http://www.ietf.org/id/draft-perrault-behave-natv2-mib-02.txt

Using the line numbers contained in the IDNits output generated by the URL at the bottom of this message, I have to say that the following statement is incorrect:

<quote>
            But the NAT
168	   binding entry defined in the NATV2-MIB are not extended by the object
169	   definded for the tunnel initiator.
</quote>

Here is what the NATv2-MIB document has, in the address binding table:

    natv2AddressMapInternalAddress OBJECT-TYPE
        SYNTAX InetAddress
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
            "Source address of packets originating from the interior
             of the association provided by this mapping.

             In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel
             source address.  The mapping in this case is considered to
             be from the combination of the IPv6 tunnel source address
             natv2AddressMapInternalRealmAddress and the well-known IPv4
             inner source address natv2AddressMapInternalMappedAddress to
             the external address."
        REFERENCE
            "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
             Section 6.6 on the need to have the IPv6 tunnel address in
             the NAT mapping tables."
        ::= { natv2AddressMapEntry 4 }

....

    natv2AddressMapInternalMappedAddress OBJECT-TYPE
        SYNTAX InetAddress
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Internal address actually translated by this mapping. In the
             general case, this is the same as
             natv2AddressMapInternalRealmAddress. In the case of DS-Lite
             [RFC 6333], this is the source address of the encapsulated
             IPv4 packet, normally lying the well-known range
             192.0.0.0/29. The mapping in this case is considered to be
             from the combination of the IPv6 tunnel source address
             natv2AddressMapInternalRealmAddress and the well-known IPv4
             inner source address natv2AddressMapInternalMappedAddress to
             the external address."
        REFERENCE
            "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
             Section 6.6 on the need to have the IPv6 tunnel address in
             the NAT mapping tables."
        ::= { natv2AddressMapEntry 7 }

and similarly in the port binding table:

    natv2PortMapInternalRealm OBJECT-TYPE
        SYNTAX SnmpAdminString (SIZE(0..32))
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "The realm to which natv2PortMapInternalRealmAddress belongs.
             In the general case, this realm contains the address that is
             being translated. In the DS-Lite [RFC 6333] case, this realm
             defines the IPv6 address space from which the tunnel source
             address is taken. The realm of the encapsulated IPv4 address
             is restricted in scope to the tunnel, so there is no point
             in identifying it separately."
        REFERENCE
            "RFC 6333 DS-Lite."
        ::= { natv2PortMapEntry 7 }

    natv2PortMapInternalAddressType OBJECT-TYPE
        SYNTAX InetAddressType
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Address type for addresses in the realm identified by
             natv2PortMapInternalRealm."
        ::= { natv2PortMapEntry 8 }

    natv2PortMapInternalAddress OBJECT-TYPE
        SYNTAX InetAddress
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Source address for packets received under this mapping on
             the internal side of the NAT instance. In the general case
             this address is the same as the address given in
             natv2PortMapInternalMappedAddress. In the DS-Lite case,
             natv2PortMapInternalAddress is the IPv6 tunnel source
             address."
        REFERENCE
            "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
             Section 6.6 on the need to have the IPv6 tunnel address in
             the NAT mapping tables."
        ::= { natv2PortMapEntry 9 }

    natv2PortMapInternalMappedAddressType OBJECT-TYPE
        SYNTAX InetAddressType
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Internal address type actually translated by this mapping.
             Any value other than ipv4(1) or ipv6(2) would be unexpected.
             In the general case, this is the same as given by
             natv2AddressMapInternalAddressType. In the DS-Lite
             case, the address type is ipv4(1)."
        REFERENCE
            "DS-Lite: RFC 6333."
       ::= { natv2PortMapEntry 10 }

    natv2PortMapInternalMappedAddress OBJECT-TYPE
        SYNTAX InetAddress
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "Internal address actually translated by this mapping. In the
             general case, this is the same as
             natv2PortMapInternalRealmAddress. In the case of DS-Lite
             [RFC 6333], this is the source address of the encapsulated
             IPv4 packet, normally selected from the well-known range
             192.0.0.0/29. The mapping in this case is considered to be
             from the external address to the combination of the IPv6
             tunnel source address natv2PortMapInternalRealmAddress and
             the well-known IPv4 inner source address
             natv2PortMapInternalMappedAddress."
        REFERENCE
            "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
             Section 6.6 on the need to have the IPv6 tunnel address in
             the NAT mapping tables."
        ::= { natv2PortMapEntry 11 }



On 13/03/2015 10:34 PM, Yong Cui wrote:
> Hi authors,
>
> We would like to advance the document.
> Would you please update your document according to the following "Check nits" report once the submission system opens? I found there are still some issues in your new version draft-ietf-softwire-dslite-mib-08.
>
> http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/dr
> aft-ietf-softwire-dslite-mib-08.txt
>
> I would also need to receive the confirmation to the chairs from each of your authors on the IPR issue:
> Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
>
> Thanks in advance,
>
> Yong
>
> On 2015-2-9, at 上午10:44, Fuyu (Eleven) <[e-mail]> wrote:
>
>> Hi Tom
>>
>> Yes. I have updated the DS-Lite MIB based on draft-perrault-behave-natv2-mib.
>> Your review and comments will be very appreciated.
>>
>> Thanks
>>
>> BR
>> Yu
>>
>> -----Original Message-----
>> From: Softwires [mailto:[e-mail]] On Behalf Of Tom 
>> Taylor
>> Sent: Friday, February 06, 2015 5:34 AM
>> To: Yong Cui; [e-mail]
>> Subject: Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07
>>
>> I finally got around to looking at this document, but I see I'm a bit late. In any event, I believe the authors are updating it based on the fact that [I-D.ietf-behave-nat-mib] is being replaced by draft-perrault-behave-natv2-mib. I will be happy to review the updated draft, because coordination between the two drafts is clearly required.
>>
>> Tom Taylor
>>
>> On 21/01/2015 7:05 AM, Yong Cui wrote:
>>> Hi folks,
>>>
>>> This message starts a two week softwire working group last call on 
>>> advancing the draft of DS-Lite MIB as a Standards Track RFC.
>>>
>>> After we had the first wglc on draft-ietf-softwire-dslite-mib-02,
>>> there were some major comments. The authors have revised the 
>>> document including the structure and detailed technical contents.
>>> Now the authors believe that this version has addressed all the 
>>> issues.
>>>
>>> The latest version of the draft is available at:
>>> http://www.ietf.org/id/draft-ietf-softwire-dslite-mib-07.txt
>>>
>>> Substantive comments and statements of support/opposition for 
>>> advancing this document should be directed to the mailing list.
>>> Editorial suggestions can be sent directly to the authors. This last 
>>> call will conclude on February 3, 2015.
>>>
>>>
>>> Thanks,
>>>
>>> Yong & Suresh
>>>
...