Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-03

[ssenthil <[e-mail]>]

Thanks for the comments. Please see inline


On 11/10/11 10:30 AM, "Dave Thaler" <[e-mail]> wrote:

> 1) The abstract says:
>> The lack of a consistent way makes it difficult to write
>> the collector applications that would receive this data and process
>> it to present useful information.
> 
> However the document only discusses data objects not a specific
> mechanism to retrieve them.   As such, the statement above is still
> true because there's no consistent way to receive such data.
> So what problem is this trying to solve?   And is it useful without
> specifying what protocol to use?

The problem we are trying to solve is as specified above, to be able to
write applications that can collect and process them without having to deal
with vendor specific implementations. I believe trying to specify the
protocol to use to transport the data objects is beyond the scope of this
specification. We could recommend some protocol if that would make this
specification complete.


> 
> 2) Section 1 says:
>> The usage of the term "NAT device" in this document refer to any
>> NAT44, Firewall and NAT64  devices.
> 
> The term NAT64 by itself includes both stateful NAT64 and stateless NAT64.
> Why would logging be required for stateless devices?
> Furthermore, the abstract talks about CGNs (where logging makes sense).
> Why would the requirements in this document apply to "any" device (as
> opposed to only CGNs) including CPE home gateways?   I didn't see any
> text discussing or justifying this statement.
> If this really is just about logging requirements for CGNs then this should
> be discussed in the context of the CGN requirements document.

Some NATs might not require it - like CPEs, but there are NATs deployed in
enterprises too (they don't have to come under the CGN umbrella) and that
would still require a logging function.

> 
> 3) The document uses several terms without defining them:
> "template", "address realm", "VRF", "NAT session", etc.
> 

Ok, I will address them in the next revision.

> 4) Section 4 says:
>> Prior to logging any events, the NAT device MUST send the template  of
>> the record to the collector to declare the format of the data record
>> that it is using to send the events.
> 
> The above MUST might make sense for a specific protocol, but since this
> document currently doesn't require any specific protocol the MUST doesn't
> make sense.   For example, if the protocol is SNMP Traps or InformRequests,
> then the format is specified in a MIB and there's no
> need for the NAT device to send it a MIB.   Similarly for any other protocol
> the collector might have some other way of getting the template from
> somewhere other than the NAT device.
> 

I am not sure I see the connection between the protocol specification and
the ability to send templates. The reason for sending the template is that
the same device could be sending multiple templates (one for nat44 create
event and the other for NAT64 delete event and another for a NAT44 quota
exceeded event. All of them carry different data sets and hence the template
is necessary. 

> 5) Section 4.1-4.3:
> Some of these seem underspecified by comparison to what I'm used to
> in MIBs.   (e.g., what's the format of "timestamp"?  what are the units?
> since when?  Local time or UTC?)  This would be cleaner if done in some
> formal way like SMIv2 or whatever, which can reference well-defined
> data types.   And then no new "NAT Event Logging" registry would be
> needed from IANA either.
> 

Ok. But for NAT specific types like a translatedAddress and port those types
have to be defined.

> 6) Section 4.1:
> This defines "MAC address" as 48 bits which is too link-type specific.
> A generic document that claims to apply to "any NAT device"
> should be link-type agnostic.  (Same comment goes for "VLAN ID".)
> 
> 7) Section 4.3.11:
> The text confuses "user" with "source address".  They're not the same thing.
> There can be many users per source address, as well as multiple source
> addresses per user.
> 
If I reword this as follows, would that be better?

"The examples of Quota exceeded are to allow only certain number of NAT
sessions per device, certain number of NAT sessions per subscriber etc."

Thanks
Senthil

> -Dave
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave