Subject: RE: [NSIS] Filters for the flow specification for the measurementin the Metering NSLP

From: "Cheng Hong" <[email-masked]>
Date: Tue, 25 Oct 2005 10:42:46 +0800

Hi Ali, and all,

I would like to support having a certain level of flexibility. We have seen
some similar requirements from the other NSLP applications, i.e. the QoS
NSLP. There are cases that the MRI is not sufficient for the flow
specification, and additional information is necessary. PACKET_CLASSIFIER in
QoS NSLP is probably trying to provide such flexibility, but it still relies
too much on the MRI. Sometimes it is good to allow a flow specification that
is not presented in the MRI. 

We have submitted a Internet Draft on the packet classification issues
(temporary available at:
http://www.psl.com.sg/internet-drafts/draft-cheng-nsis-flowid-issues-02.txt)
. It discussed some of the relevant issues you mentioned below (although
more in the QoS NSLP context).

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Ali Fessi
> Sent: Monday, October 24, 2005 10:59 PM
> To: Roland Bless
> Cc: Falko Dressler; nsis; Tschofenig Hannes; Changpeng Fan; Kappler 
> Cornelia
> Subject: Re: [NSIS] Filters for the flow specification for the 
> measurementin the Metering NSLP
> 
> Hi Roland, hi Juergen and all,
> 
> Roland Bless wrote:
> 
> > IMHO it would be good to be at least more flexible in the
> sense that
> > you're interested in a subset of the aggregate that is
> defined by the
> > MRI between A and B. For example, I think it is perfectly
> legitimate
> > to measure or sample only certain TCP packets (as in your example
> > above) or certain ICMP messages or even particular HTTP messages.
> > So the MRI would match an aggregate flowing from A to B, and you're 
> > interested in a particular sub aggregate within. So the
> logic within
> > the NSLP could check the semantics, i.e. whether the filter is 
> > actually picking a subset of the MRI.
> > 
> > OTOH I can imagine a scenario where you are configuring filter for 
> > packets that are normally and currently *not* flowing on
> the path from
> > A to B. So the filter would be used to detect/measure some failure 
> > conditions or anomalies. In this case it would be even useful to 
> > configure filters along
> > A->B so that they match flows that are currently not routed
> > along that path.
> > 
> > Best regards,
> >  Roland
> > 
> 
> both scenarios sound meaningful to me. I'm also in favor a flexible 
> flow specification in the MSPEC and think it would give the Metering 
> NSLP a broader applicability. But I currently see the following 
> challenges:
> 
> - verifying the semantic of the flow specification in the MSPEC and 
> its relationship to the MRI will be scenario dependant which will make 
> it more complex and error prone
> 
> - Authorizing Metering NSLP configuration messages with a flexible 
> flow spec will be also more complex, since the whole MSPEC needs to be 
> verified against a set of security policies which will be also 
> dependant on the application scenario and can not be generalized.
> 
> - NAT traversal: when crossing a NAT, the flow specification in the 
> MSPEC will need to be updated. This means that the M-NSLP will need to 
> look for the fields in the flow spec that need to be modified and 
> modify them correctly according to the NAT binding. This might be not 
> easy, if e.g. some port ranges and IP address netmasks, etc.
> 
> Looking at these issues, it seems to be a hard job to solve them and 
> I'm currently not sure what is the best solution?!
> 
> Any comments are welcome!
> 
> Best regards,
> Ali.
> --
> Ali Fessi
> University of Tuebingen, Germany
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis