Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04

From: Gerhard Muenz <[email-masked]>
Date: Mon, 01 Mar 2010 09:43:12 +0100

Hi Atsushi,

Atsushi Kobayashi wrote:
> Hi Gerhard, and all,
> 
> I find my following answer could not have been shared in list due to our
> network trouble.

Thank you for you comments. As far as I can see, there are only two 
issues left:

1) Match Filters

>>>>>>> 4.2.3.  Filter Classes
>>>>>>>
>>>>>>>            +--------------------------+
>>>>>>>            | FilterMatch              |
>>>>>>>            +--------------------------+
>>>>>>>            | ieId/ieName              |
>>>>>>>            | ieEnterpriseNumber[0..1] |
>>>>>>>            | value                    |
>>>>>>>            +--------------------------+
>>>>>>>                          Figure 10: Filter classes
>>>>>>>
>>>>>>>    The Filter classes in Figure 10 contain the configuration parameters
>>>>>>>    of specific Filtering methods.  For property match filtering, the
>>>>>>>    configuration parameters are:
>>>>>>>
>>>>>>>    ieId, ieName, ieEnterpriseNumber:  The property to be matched is
>>>>>>>       specified by either ieId or ieName, specifying the ID or name of
>>>>>>>       the Information Element, respectively. ieEnterpriseNumber MUST be
>>>>>>>       used for enterprise-specific Information Elements.  If
>>>>>>>       ieEnterpriseNumber is omitted or zero, this is Information Element
>>>>>>>       is not enterprise-specific but registered at IANA.
>>>>>>>
>>>>>>>    value:  Matching value.
>>>>>>>
>>>>>> Can the ranges of value be defined like hash value?
>>>>> No.  The reason is that min/max fields are not specified in the Selector 
>>>>> Report Interpretation:
>>>>> http://tools.ietf.org/html/rfc5476#section-6.5.2.5
>>>>>
>>>>> In the case of FilterHash, we do min/max fields in the Selector Report 
>>>>> Interpretation:
>>>>> http://tools.ietf.org/html/rfc5476#section-6.5.2.6
>>>>>
>>>>>> And, I would like to specify its instruction, "match" or "unmatch".
>>>>> This is not specified in the Selector Report Interpretation. Therefore, 
>>>>> we cannot allow configuring this.
>>>>>
>>>> Above all, they apparently would be required from viewpoint of usability.
>>> I agree. But this is not the document to solve this problem.
>>>
>>>> Please see http://tools.ietf.org/html/rfc5475#section-6.1 that described
>>>> it as an extension of the basic model.
>>>>
>>>> Implementor will add above functions because only exact match is too
>>>> poor. In that case, can IPFIX-CONFIG expand to add these functions? 
>>>> How does it expand?
>>> The model can be extensible by vendors or in later revisions of the model.
>>>
>> Ok, I understood what you would like to say. I am concerned that the
>> extensions are built indiscriminately.

To summarize this issue: PSAMP protocol only specifies simplistic match 
filters, and the current configuration data model supports the 
configuration of such filters.

If the IPFIX WG wants the configuration data model to offer more 
configuration possibilities than simple match filters, the WG must be 
aware of the fact that this Selector configuration cannot be reported 
within a Selector Report Interpretation.

Therfore, I will not extend the configuration data model unless we have 
reached consensus within the IPFIX WG that this restriction is not a 
problem.

2) sourceIpAddress of an Exporting Process

>>>>>>>    sourceIpAddress:  This parameter sets the source IP address.  If this
>>>>>>>       parameter is omitted, the address assigned to the outgoing
>>>>>>>       interface is used.
>>>>>>>
>>>>>> I would like to make available in the case of TCP.
>>>>> We adopted this parameter because the Cisco CLI has it for UDP.  As far 
>>>>> as I understand, it is not used to specify the outgoing interface but 
>>>>> the (forged) source address in the IP header only.
>>>>>
>>>> No. In current network operation, source IP address is important
>>>> parameter as a indicator of exporting device(router). Operators are
>>>> often confused that a source IP address is changed when route changes
>>>> happen. Exporting device may select source address as a optimal exit points, or
>>>> arbitrarily.  Then, some collectors may fail to recognize identical
>>>> exporting device before and after route changes.
>>>  >
>>>> This function is necessary to avoid the confusion.
>>> I will ask Benoit how this parameter is used.
>>>
>>>>> How do you want to forge the IP address of a TCP endpoint?  It must 
>>>>> belong to the interface.
>>>>>
>>>>> The parameter description remains unclear in the case of multiple 
>>>>> addresses assigned to a single interface.
>>>>>
>>>>> I'm not sure what to do.
>>>>> We can remove the parameter.
>>>>> We can change to "...one of the addresses assigned to the outgoing 
>>>>> interface is used."
>>>>> We can try to find a generic solution that defines the outgoing interface.
>>>> I propose the following.
>>>>
>>>> The following parameters are applicable if TCP or UDP is transport
>>>> protocol:
>>>>
>>>> sourceIpAddress:  This parameter sets the source IP address. 
>>>> If this parameter is omitted, Exporter selects outgoing interface
>>>> according to routing policy, and then arbitrarily assigns the address.
>>> You cannot use an arbitrary source IP address with TCP.
>>>
>> I mean exporting device may select appropriate source ip
>> address as TCP client along with routing policy if the parameter is
>> omitted. The routing policy may change between before and after its
>> shutdown or link-failure, etc. This may cause in the case of TCP.
>>
>> In simple example, if you can use source IP address on loopback, it
>> avoid this problem.

After discussing this issue with you and Paul, I've learned that the 
source IP address parameter can be configured independently from the 
interface.

A note about how this works on *ix systems:
The IP address is configured with bind() while the interface is 
configured with socket option SO_BINDTODEVICE. In the case of SCTP, 
multiple source IP can be bound using sctp_bindx().

So, I propose to have the parameter sourceIpAddress for all transport 
protocols. In the case of SCTP, it replaces localIPAddress and thus may 
appear more than once.
In addition, I propose to add parameters ifIndex/ifName to optionally 
specify the interface.

NEW:

4.4.1.  Destination Class

    +------------------------------------------------+
    | Destination                                    |
    +------------------------------------------------+
    | name                                           |<>-----+
    | exportMemberType = parallel                    |       | 0..1
    | ipfixVersion = 10                              |       |
    | transportProtocol                              |   +------------+
=> | sourceIpAddress[0..*] {[0..1] for UDP and TCP} |   | Transport- |
    | destinationIpAddress                           |   | Layer-     |
    | destinationPort = 4739|4740                    |   | Security   |
=> | ifName/ifIndex[0..1]                           |   +------------+
    | sendBufferSize {opt.}                          |
    | rateLimit[0..1]                                |
    | timedReliability = 0 {SCTP only}               |
    | numberOfStreams {opt.} {SCTP only}             |
    | templateRefreshTimeout = 600 {UDP only}        |
    | optionsTemplateRefreshTimeout = 600 {UDP only} |
    | templateRefreshPacket[0..1] {UDP only}         |
    | optionsTemplateRefreshPacket[0..1] {UDP only}  |
    +------------------------------------------------+
                        Figure 14: Destination class

    sourceIpAddress:  This parameter specifies the source IP address(es)
       used by the Exporting Process.
       If the transport protocol is SCTP, this parameter MAY appear
       multiple times to specify the list of eligible local IP addresses
       of a multi-homed Exporting Process [RFC4960].  If this parameter
       is omitted and the transport protocol is SCTP, all locally
       assigned IP addresses are eligible local IP addresses.
       If the transport protocol is UDP or TCP, this parameter MAY appear
       only once. If this parameter is omitted and the transport protocol
       is UDP or TCP, the IP address assigned to the outgoing interface
       is used as source IP address.

    ifIndex/ifName:  Either the index or the name of the interface used
       by the Exporting Process to export IPFIX messages to the given
       destination MAY be specified according to corresponding objects in
       the IF-MIB <xref target="RFC2863"/>.  If omitted, the Exporting
       Process selects the outgoing interface based on local routing
       decision and accepts return traffic, such as transport layer
       acknowledgments, on all available interfaces.

Do you agree with these changes?

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Atsushi Kobayashi <[email-masked]>
Date: Tue, 02 Mar 2010 21:19:05 +0900

Hi Gerhard,

Thank you for your reply. Please see in-line.

On Mon, 01 Mar 2010 09:43:12 +0100

> reached consensus within the IPFIX WG that this restriction is not a 

To keep consistency for these documents, it seems to be better to remain
this restriction. I hope that "match", "unmatch", and range filter can
be applied to it in near future. A document for these expansions would
cover the CONFIG-MODEL and selector representation using structured data.

I would like to know other IPFIX member's comments, could you please
bring up this topics in next meeting.

> In addition, I propose to add parameters ifIndex/ifName to optionally 

Almost OK, but there are two questions.
I wonder why you need ifName? I think only sourceIpAddress is enough.
And also, when ifName,ifIndex, and sourceIpAddr are set in CONFIG, which
one is applied to source ip address?

Regards,
Atsushi

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 02 Mar 2010 14:56:54 +0100

Hi Atsushi,

Please see inline.

> bring up this topics in next meeting.

Yes, I can put this on the slides.

> one is applied to source ip address?

This is something which confused my as well, but Paul put me on the 
right track.

I try to explain:

If you do not bind the socket to a specific (link-layer) interface, the 
OS will look into the routing table and choose the outgoing interface 
with the lowest routing costs to the destination. The source IP address 
does not matter at all in this decision. Even in the case of TCP, 
asymmetric routing may lead to the effect that outgoing packets are sent 
on one router interface and incoming packets are received on another 
interface. This is a valid TCP connection.

As administrator, you want to enforce that IPFIX messages leave the 
router on the management interface, independently of the routing table. 
This is done with ifName/ifIndex.

Is it clear now?

Regards,
Gerhard

---

From: Atsushi Kobayashi <[email-masked]>
Date: Fri, 05 Mar 2010 18:01:59 +0900

Hi Gerhard,

On Tue, 02 Mar 2010 14:56:54 +0100
>>        acknowledgments, on all available interfaces.

I understood. They are fine. Thank you.

Regards,
Atsushi

> This is done with ifName/ifIndex.

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637