Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

["Teague, Nik" <[e-mail]>]

Marvin hi,

Some feedback on the mechanism…

Many networks deploy architectures where separate perimeter routers connect to any number of providers.  Traffic, as a result, is often asynchronous – i.e. the best path _out_ is not always the best path _in_ (for any number of reasons… bgp is policy based remember).  Therefore, a device that handles inbound packets for a flow may not be the same one dealing with outbound.  This means your IE’s may be rendered generally useless depending upon whether or not you, somehow, pin traffic to a path (which would probably be vulnerable then to exploitation).  There have been a few implementations that try and stitch flows together (ibm’s qflows come to mind) but these are generally done at the collection/analysis layer vs locally on a router.

Thanks,

-Nik

On 13/03/2017, 07:37, "Dots on behalf of Zhenghui (Marvin)" <[e-mail] on behalf of [e-mail]> wrote:

    Hello DOTS WG,
     
    We have submitted a draft draft-fu-dots-ipfix-tcp-tracking-00, which is the succession of draft-fu-dots-ipfix-extension-01.
    
    The original draft has been reviewed internally. As a result,  the IPFIX Information Elements inside the draft have been revised, and some of the IEs are removed.
     
    However, we’ve realized what our draft intends to do is not what currently DOTS WG is focusing on.
    So, we’d like to hear from the WG, is that some pointers can be given on the next step of the draft, or where we can continue the discussion of the issue that the draft addresses.
     
    We submitted this draft to DOTS because IPFIX WG had been closed, and DOTS was the best match we found.
     
    Thanks.
     
    Marvin Zhenghui
    Best Regards