Re: [BEHAVE] New Version Notification for draft-sivakumar-behave-nat-logging-04.txt

[Senthil Sivakumar <[e-mail]>]

Thanks for the review.

On 6/18/12 4:35 PM, "Simon Perreault" <[e-mail]> wrote:

>On 2012-06-15 14:52, Senthil Sivakumar wrote:
>> A new version of the logging draft is posted that is focused towards
>>using
>> IPFIX Information
>> Elements for NAT logging. Please review and provide feedback.
>
>Looks good!
>
>Question: why did you unite vlan ID and VRF ID? Aren't they orthogonal
>things?

There are two information elements one for VLAN ID and one for VRF ID,
they are listed under Table 1.
In the actual events, I mentioned them as one entity as VlanID/VRF ID, the
reason being either one of them is used
to uniquely identify a private address but not both.

>
>Observation: the term BIB is defined in RFC6146 but only in the context
>of NAT64. Yet this draft uses it in the context of NAT44. I foresee
>problems.

Ok, would it help if I change it to NAT44 binding instead of NAT44 BIB?

> For example, it is not clear how a fully symmetric NAT (which
>has no BIB) would use this. Would it only log session events and never
>BIB events? Also, what about NATs that don't track sessions? Would they
>just log BIB events and never session events?

Correct, the NATs that don¹t track the full 5 tuple sessions wont log the
full session.
Similarly the NATs that don¹t have the Binding database but not the
session database will not log the session entry.

>
>What about NAT46 and NAT66? Are they supported?

NAT46 can be accomodated in the NAT64 record itself, can it not? Wondering
if we need to address NAT66 as it is neither an RFC nor a product.

>
>Lastly, I see feature overlap between this draft and the MIB draft for
>the addresses exhausted, ports exhausted, and quota exceeded event. Do
>we really want to provide two ways of doing the same thing?

I was going through the same thoughts myself. But I have had people asking
these events to be logged.
I think this is where logging is not just for tracking individual users
but crosses into the management domain.
But I also think that people using SNMP wouldn¹t want to log these events.

Thanks
Senthil

>
>Simon
>-- 
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/behave