Subject: [v6ops] draft-sivakumar-yang-nat-01.txt)

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 8 Sep 2015 16:18:11 +0000

The authors of draft-sivakumar-yang-nat are looking for a home for it. This is a YANG management model for NATs, including NAT64, NPTv6, and other variants.

In the revised charter filed with the IESG, this would be most similar to the third issue, which is a catch-all. It fits if we say that it fits. https://datatracker.ietf.org/doc/charter-ietf-v6ops/. There may also be other options; I am specifically asking the sunset4 chairs whether it fits there, and one wonders about int-area. The obvious working groups, behave and softwire, are closed or closing.

My question for the moment is a simple one: many of us are looking at YANG as a network management model; would a YANG model for a translator be useful to those operating 464XLAT, SIIT-DC, MAP-T/E, or other networks that target IPv6 operation and require translation of some type? If so, would this be a useful starting point, and would this working group be an appropriate place to discuss it? I have copied the authors of network management efforts related to NAT and some operators I know are using it.

If in answering the question anyone were to review the document and compare it to RFC 4008 or other models for information and structure to be modeled, I imagine the authors would appreciate that.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 15 Sep 2015 10:44:00 -0400

Metacomment: work up to now on NAT MIB and logging has been cross-posted 
to the Behave and OPSAWG lists.

The module looks reasonable. One general point concerns me, and may be 
applicable to other Yang documents. To make the module completely 
intelligible, there should be a description of the applicability of its 
various components to particular use cases. Is the intention to have 
such discussion in the Yang module document itself or in a separate 
document?

On a specific technical point: the module restricts itself to an 
enumeration of transport protocols: UDP, TCP, and ICMP. I thought one of 
the lessons learned from NAT-MIB-V1 was that the protocol list should be 
generalized. On the other hand, when I went to apply this principle in 
suggesting compliance in NAT-MIB-V2, I found it a little tricky to 
decide just which values in the IANA protocol registry should be supported.

I note that only the pool-related notifications are supported, in 
contrast to the broader set defined by the MIB module. I'll be happy to 
have comments on that. The statistics are also presented at a courser 
granularity only, I think, but I will have to do a detailed comparison 
to be sure. These are just my impressions from skimming over the document.

A few detailed comments:

On timeouts: units should be stated.

What is the difference between mapping-limit and connection-limit?

Typo: s/leaf port-preservation-suport/leaf port-preservation-support/

Typo: under "leaf port-free": s/addresses/ports/ in the description

Tom Taylor

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Thu, 17 Sep 2015 15:49:07 +0000

The applicability is broad enough to cover most of the use cases, I don¹t
think 
we need to restrict ourselves to specific use cases. The intention here
Is to capture the commonality in MOST of the use cases, and leave the
vendor specific implementation details to specific vendors.

The transport protocol field in the mapping table can represent protocols
other than TCP/UDP/ICMP. But the TCP/UDP/ICMP are well defined in the NAT
behave
RFCs that require certain behavior and hence the config options for them.

The notifications are currently the low threshold for pools and ports, it
can be
extended to have high threshold like we have in the MIB.

The mapping limits are for static mappings, connection limits are
dynamically created mappings.

Thanks for the other editorial comments, we will take care of it in the
next rev.

Thanks
Senthil

On 9/15/15, 10:44 AM, "Tom Taylor" <[email-masked]> wrote:

>> The authors of draft-sivakumar-yang-nat are looking for a home for it.
>>This is a YANG management model for NATs, including NAT64, NPTv6, and
>>other variants.
>>
>> In the revised charter filed with the IESG, this would be most similar
>>to the third issue, which is a catch-all. It fits if we say that it
>>fits. https://datatracker.ietf.org/doc/charter-ietf-v6ops/. There may
>>also be other options; I am specifically asking the sunset4 chairs
>>whether it fits there, and one wonders about int-area. The obvious
>>working groups, behave and softwire, are closed or closing.
>>
>> My question for the moment is a simple one: many of us are looking at
>>YANG as a network management model; would a YANG model for a translator
>>be useful to those operating 464XLAT, SIIT-DC, MAP-T/E, or other
>>networks that target IPv6 operation and require translation of some
>>type? If so, would this be a useful starting point, and would this
>>working group be an appropriate place to discuss it? I have copied the
>>authors of network management efforts related to NAT and some operators
>>I know are using it.
>>
>> If in answering the question anyone were to review the document and
>>compare it to RFC 4008 or other models for information and structure to
>>be modeled, I imagine the authors would appreciate that.
>>

---

From: <[email-masked]>
Date: Fri, 18 Sep 2015 07:30:49 +0000

Hi all,

I fully agree with Senthil. 

Cheers,
Med

> -----Message d'origine-----
> De : Senthil Sivakumar (ssenthil) [mailto:[email-masked]]
> Envoyé : jeudi 17 septembre 2015 17:49
> À : Tom Taylor; Fred Baker (fred); v6ops list
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Immo Wehrenberg
> Objet : Re: draft-sivakumar-yang-nat-01.txt)
>