Subject: [BEHAVE] Differences between draft-ietf-behave-syslog-nat-logging-04 and draft-ietf-behave-ipfix-nat-logging-01

From: Tom Taylor <[email-masked]>
Date: Fri, 04 Oct 2013 20:58:09 -0400

My promised comparison of the SYSLOG and IPFIX drafts is attached as a 
text file. I guess Senthil and I can work out some of the issues listed 
below in our role as editors, and whatever is left over can go to the 
list as separate messages.

Senthil, the PDF version you got earlier had some errors for IPFIX, 
which are corrected in the text file.

Tom Taylor

Issues Identified
=================

1. SYSLOG has an event for address mapping delete as well as create. 
IPFIX is create only. Are address mappings forever?

2. IPFIX Quota event not same as SYSLOG Quota event, actually 
corresponds to other SYSLOG/MIB events plus one that SYSLOG and MIB do 
not cover.

3. General difference in which operations and maintenance oriented 
events IPFIX and SYSLOG/MIB cover.

4. What is the best granularity for event type for the resource 
allocation related events?

(a) By resource: Session, BIB, Address Mapping, Port Set with sub-events 
for actions create/delete (allocate/deallocate).

(b) Resource + action (e.g., session create, session delete, BIB entry 
create, BIB entry delete, etc.) -- current SYSLOG approach.

(c) Resource + action + NAT type (e.g., NAT44 session create, etc.) -- 
current IPFIX approach.

Factors to consider:
   -- effect on routing, but seems likely all of these logs would go to 
the same collectors
   -- effect on record lengths and search effort when extra parameters 
needed to distinguish action, address types involved
   -- flexibility in accommodating new NAT types.

5. SYSLOG expects realm to be an administered text field, potentially 
mapped to a VLANId, VRFId, or SWID in a MIB table, and makes it a 
mandatory parameter required for both the internal and external sides of 
a mapping. IPFIX makes internal realm an 8-bit binary optional field and 
has no external realm. (To accommodate GW-initiated DS-Lite, realm 
should be 16 bits so it can hold a SWID.) IPFIX has VLANId/VRFId as an 
optional additional parameter.

(a) Should realm be text or binary?

(b) Understanding that not all realms will have such a mapping, can 
realm map to VLANId, VRFId, or SWID, or are these separate concepts?

(c) Should internal realm be optional or mandatory?

(d) Is external realm required, at least in some cases, and should it be 
optional or mandatory?

6. No provision in IPFIX for identifying subscriber site when 
realm-unique IPv4 or IPv6 address is unavailable (i.e., using 
GW-initiated DS-Lite CID based on GRE, MPLS, or IPv6 Flow Label).

7. IPFIX session event makes destination address and port information 
optional. A session event without that information is identical to a BIB 
event, so there is no point in reporting it. Shouldn't destination info 
be mandatory?

8. SYSLOG has TRIG for nearly every event, optional for the resource 
allocation related ones, mandatory for some of the operations and 
maintenance oriented ones. It was my personal judgement that this would 
be useful, particularly in interpreting MIB counters in the O&M cases. 
The MIB counters count packet drops when failed requests are triggered 
by packet arrivals, but nothing counts failed administrative requests 
(which SYSLOG assumes include PCP requests). Do operators see TRIG as 
needed?

9. Disagreement between SYSLOG and IPFIX regarding port set 
allocation/deallocation, specifically with respect to the RGLEN versus 
portRangeNumPorts parameters. SYSLOG was inspired by MAP-style 
allocations, which won't be logged, so the question is what sort of 
allocations/deallocations will happen and do need to be logged. IPFIX 
parameter usage seems to have more than one way to specify the same thing.

10. SYSLOG assumes port (de)allocation pertains to an address mapping, 
hence internal address information is mandatory. IPFIX makes the 
internal address information optional. True, the allocation is to the 
external address, but it is on behalf of a particular host, which should 
be identified.

11. Presumably IPFIX needs management capabilities similar to those 
documented in the SYSLOG Management Considerations section.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 7 Oct 2013 16:17:36 +0000

>which are corrected in the text file.

No, you are right, I will fix it.
>corresponds to other SYSLOG/MIB events plus one that SYSLOG and MIB do

IPFIX quotas are for specific events, like session entry limit, bib limit
And per-user limit. I am fine with adding specific events to be compatible
with
Syslog draft, but the syslog draft is generic to accommodate any kind of
quota.
That can be accomplished with the string based free form approach that
syslog is 
Using but not with IPFIX.

>events IPFIX and SYSLOG/MIB cover.

Was there consensus in the WG for reporting the high/low threshold for
pool and address mapping events?
If so, I am fine with adding the high/low threshold events to be reported
via IPFIX as well. 

>   -- flexibility in accommodating new NAT types.

Obviously, for a binary format export like IPFIX, c works the best.
Clear, specific events with an event ID, helps the collectors to identify
the events,
Without having to combine multiple identifiers to decipher the actual
event. 

>(a) Should realm be text or binary?

Binary, any reasons it should be text?

>(d) Is external realm required, at least in some cases, and should it be

Both internal and external realms should be optional, IMO.

>event, so there is no point in reporting it. Shouldn't destination info

The destination information is not mandatory. There are nat44
implementations 
has a session database but doesn¹t need to log the destination information.
You can call that as BIB, but that is purely semantics on how you want to
call that as.

>parameter usage seems to have more than one way to specify the same thing.

I think we need some external input on the port set
allocation/deallocation.

>external address, but it is on behalf of a particular host, which should

The port block allocation/deallocationg message in IPFIX shows that
sourceIPv4
Or sourceIPv6 should be present. I received a comment from the mailing
list 
To somehow communicate that it is one or the other is mandatory, I have to
capture this in the
Document.

>documented in the SYSLOG Management Considerations section.

I agree, I will add it to the next rev.

Regarding the parameter differences, I will address them in a separate
thread.

Thanks
Senthil