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

[ssenthil <[e-mail]>]

On 11/10/11 6:16 PM, "Dave Thaler" <[e-mail]> wrote:

> Ssenthil writes: 
>>> 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.
> 
> This draft does not currently allow you to write apps that collect and process
> them without having to deal with vendor specific implementations.  To get
> that, you'd have to specify what protocol to use.  Otherwise you have to
> deal with vendor specific protocol code anyway so you haven't met your
> stated goal.

There are many choices of the protocol that can be used to transport the
data. But we wanted to stay away from getting into exact recommendation of
the protocol to use.

> 
>>> 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.
> 
> Ok.  Since you agree that this does not apply to "any" device, I expect you
> will update the text accordingly.
> 
> [...]

Ok I will change the text to reflect that it is not a must for all kinds of
NAT.

> 
>>> 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.
> 
> I understand you didn't follow what I said, so I'll try to rephrase.  A NAT
> device can send all of this information to a collector without sending any
> "template" before sending the information.   Of course since you never defined
> the term template, I'm assuming it means schema.   The collector might already
> have the templates, and there's many examples of this today.
> 
I will define what a template is in the next rev. Yes, schema and template
are the same. The problem with the fixed templates is that it makes it
difficult to change and adopt to different implementations. Let me give you
an example.
If the schema/template changes the data to be exported for example an
previously optional field now becomes a part of the new template, then the
collector device need to change its template too. Having the templates sent
over dynamically provides a much greater benefit and ability to change the
schema.

Senthil