RE: [NSIS] Draft on NSIS Operation Over IP Tunnels

Hi Robert,

I see them as related yet slightly different issues.

According to my understanding, generally Flow (packet) Classfication
Information is assumed to be derived from the flow MRI.
draft-cheng-nsis-flowid-issues-01.txt discussed cases where this might not
be sufficient and it might be desired to separate the flow classification
information from MRI. 

In fact there is a related case in the NSIS tunneling analysis. Packets
inside the tunnel carry tunnel MRI in the outer header and the e2e MRI in
the innner header. The separation of the tunnel MRI and tunnel flow
classification information will occur if flows inside the tunnel are to be
classified based on the inner header. (Although note that our chosen
approach is to perform tunnel flow classification based on the outer header
due to the fact that most routers won't look at the inner header.)  

Two basic solutions to the above issue seem to be either extending the
current MRI definition or having a separate flow classification information
object. The Filter_List represents one of the latter approaches. I have a
few questions about this Filter_List mechanism and would appreciate if the
authors of draft-cheng-nsis-flowid-issues-01.txt can clarify. Sec. 6.1 says:

   Since the NTLP does not need to modify the Flow ID or MRI every time the
address changes, the state maintained on the NSIS nodes will be more stable,
and thus requires less operation in updating. 

Wouldn't the MRI change every time you have an address change? Does this
draft keep the assumption that MRI and Flow ID are tied togher? Also it
seems to me we will have one session with one SESSION ID and possibly
multiple FLOW IDs, then each FLOW ID may have multiple FILTER SPECS? Please
correct me if I misunderstood it. 

draft-shen-nsis-tunnel-00.txt discusses intra-session associaiton, i.e. to
associate different FLOW IDs (for flow classification) with the same SESSION
ID. The association may be done for different purposes, such as supporting
NSIS operation over IP tunnels. The association can be achieved in different
ways given different assumptions about the relationship between flow
classification information and MRI. Indeed, I feel that the FILTER_LIST
approach with its ADD action might serve a similar function as
ASSOCIATE_FLOW_SESSION. However, the action name might need to be made more
specific. i.e, to indicate whether this is for NSIS-tunnel handling or for
other purposes.  

Thanks.

Charles 

-----Original Message-----
From: Hancock, Robert [mailto:robert.hancock@roke.co.uk] 
Sent: Saturday, July 30, 2005 9:20 AM
To: john.loughney@nokia.com; charles@cs.columbia.edu; nsis@ietf.org
Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels

Hi, 

One thing it would be interesting to get the viewpoints of the 
various sets of authors on is whether the use case for the 
BOUND_FLOW_SESSION (in this draft) is related to the use case 
for the "Filter List" from draft-cheng-nsis-flowid-issues-01.txt 
or "Path Type" from draft-sanda-nsis-path-type-02.txt. All of 
these things seem to be about ways to link together multiple 
signalling sessions in various ways. One feels that generic 
(multi-NSLP) solutions should be possible, but it is not clear 
to me exactly how many different problems there are (or how 
many different solutions are needed). 

Robert H. 

> -----Original Message----- 
> From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On 
> Behalf Of john.loughney@nokia.com 
> Sent: 30 July 2005 11:09 
> To: charles@cs.columbia.edu; nsis@ietf.org 
> Subject: RE: [NSIS] Draft on NSIS Operation Over IP Tunnels 
> 
> 
> Hi Charles, 
> 
> Thanks for the draft, I think this is quite a useful 
> analysis.  As tunneling, like multihoming, can be related to 
> mobility, I wonder if the analysis could go into the Mobility 
> Applicability Statement document.  
> 
> After that, for the BOUND_FLOW_SESSION object, do you think 
> that this would be a general object for all NSLPs that might 
> run over a tunnel?  One option would be to add this to the 
> existing NSLPs, or to write a very short document registering 
> this as a NSLP object in the NSIS IANA registry (when there is one). 
> 
> What does the rest of the wg think? 
> 
> thanks, 
> John 
> 
> > -----Original Message----- 
> > From: nsis-bounces@ietf.org 
> [mailto:nsis-bounces@ietf.org]On Behalf Of 
> > ext Charles Shen 
> > Sent: 14 July, 2005 07:45 
> > To: nsis@ietf.org 
> > Subject: [NSIS] Draft on NSIS Operation Over IP Tunnels 
> > 
> > 
> > Dear all, 
> > 
> > We've submitted a draft on "NSIS Operation Over IP Tunnels". 
> > The abstract is 
> > as follows: 
> > 
> >    In this draft we briefly review various IP Tunnelling 
> > mechanisms and 
> >    discuss the main problems with signaling operation over 
> IP tunnels. 
> >    We also summarize the existing RSVP operation over IP tunnels 
> >    mechanism.  Then we present the design details and case 
> examples of 
> >    an NSIS operation over IP tunnels scheme.  QoS NSLP is 
> > assumed as the 
> >    NSIS signaling application in our discussion. 
> > 
> > The document is available at 
> > 
> > http://www.ietf.org/internet-drafts/draft-shen-nsis-tunnel-00.txt 
> > 
> > Any comments are greatly appreciated! 
> > 
> > Best regards, 
> > 
> > Charles 
> > 
> > 
> > 
> > _______________________________________________ 
> > nsis mailing list 
> > nsis@ietf.org 
> > https://www1.ietf.org/mailman/listinfo/nsis 
> > 
> 
> _______________________________________________ 
> nsis mailing list 
> nsis@ietf.org 
> https://www1.ietf.org/mailman/listinfo/nsis 
> 