Re: some doubts

[Nick Duffield <duffield@research.att.com>]

Senthil, comments below; see you on Tuesday. Nick.

"Ayyasamy, Senthilkumar (UMKC-Student)" wrote:
> 
> Hi all,
>    I find the draft lacks some valid details .I have listed some for your feeback
> 
> 1.The darft also doesnt talk about the transport negotiation which is very important for remote packet sampling .

I'm not sure that transport needs to be negotiated as part of the
protocol. A more lightweight approach is to have transport parameters 
in a MIB that can be configured using SNMP. This is attractive because 
there's already lots of experience with SNMP, it's reliable and allows
authentication, and it's easy to create lightweight SNMP clients on a
collector.

> 
> 2.The implementation of data collector part seems to work out more for hardware vendors.But will that not be costly ?Is there any existing such hardware implementations ? I personally feel implementation by software can be much more flexible (cost also decreases)

Certainly software is flexible, but there is a question whether
it can do per packet operations fast enough in all routers.

> 
> 3.The draft defines a remote export packet sampling .what sort of function will be employed to export remote PSAMP data.Will the existing IPFIX exporter be used ?

We still need to pin down the export requirements for PSAMP; if
there were an existing protocol that has a sufficiently rich 
information model and export capabilities for PSAMP, it would 
make sense to reuse it. But that has to be determined.

> 
> 4.Cant the exporter configuration be considered out of the scope ?.My assumption is that exporter configuration can be done by MIB (even CLI).Also,the configuration details will make the architechture complex.Avoiding exporter configuration details will support the KISS concept.

Agree, mostly. Similar to point 1 above, I think SNMP configuration 
of a MIB that included export parameters is the way to start. (CLI alone 
is too limiting). Specifying the MIB is in scope. 

> 
> 5.Is network survillance also a intended application ?
> 

A guiding principle of PSAMP is to keep things simple enough to be 
implemented on every line card; I don't expect full packet capture 
would fall into that category.

> 6.I presume explicit mentioning of MPLS FEC's  in unnessary.MPLS and ITE WG does that work and are standartizing the characterization.The group can focus on IP flows .
> 

Disagree. Knowing the FEC can have useful diagnostic value. Also,
remember
that we don't propose that PSAMP report flows (in the IPFIX sense), just 
packet level information.

> I have a doubt on what exactly is the difference between source-based aggregation and packet-based sampling.This will exactly give me an idea on what essentially is the difference between the working of PSAMP and IPFIX groups.

In PSAMP the "atomic" measurement is the packet, and a big part of
the work will be specifying how packets are sampled. There's no 
formation of flow statistics, or other keeping of state by PSAMP; 
just ship out the packet level measurements in a timely manner.

> 
> Meet you all in tuesday's PSAMP BOF
> Thanks in advance,
> -Senthil.
> 
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/psamp/>

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>