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

["Cheng Hong" <[e-mail]>]

Hi Charles,
 
> 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? 
 
The draft keeps the assumption that MRI and Flow ID are tied together.
The sentence you quoted is trying to state the fact that if the Filter
List is employed, the Flow ID's dependency on the address information
can be relaxed, and it would result in less state management, e.g. new
path discovery. Some points about this was discussed in the mailing list
after last Interim meeting. We should have expanded the text to explain
it. 
 
> 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. 
 
You are correct that there may be multiple Flows within one Session,
according to the definition of Session and Flow in NSIS, e.g. due to
mobility, multihoming, and host decisions. How these Flows relate to
each other is the question addressed in draft
draft-sanda-nsis-path-type-02.txt.  It talks about a logic Path Type
that can be used to correlate certain flows within a Session (instead of
implicitly assuming all the Flows within the Session are bound
together).  In this aspects, it related to the intra-session association
idea in your draft draft-shen-nsis-tunnel-00.txt, although looking at a
separate problem. It is trying to solve those mobility related issues. 
 
 
Also, within a same flow, there may need several Filter Specs to
accurately reflect the addresses involved. This is the issue address in
the draft-cheng-nsis-flowid-issues-01. Several scenarios/use cases were
described to illustrates the needs for this.
 
> 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.  
 
I have the same feeling here. Especially for a aggregated case, the
Filter_List approach may be useful to handle the possible disagreement
between Flow ID and FCI. I agree that to use it for that purpose, some
modifications is necessary. Takako, one of the co-author of the draft,
will attend the IETF meeting this week. So, some face to face discussion
may be able to sort out the details.
 
cheers
 
Cheng Hong
 
 
 
   
 
 
 


________________________________

	From: Charles Shen [mailto:[e-mail]] 
	Sent: Monday, August 01, 2005 12:33 AM
	To: 'Hancock, Robert'; [e-mail]; Cheng Hong;
[e-mail]
	Subject: 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:[e-mail]]

		Sent: Saturday, July 30, 2005 9:20 AM
		To: [e-mail]; [e-mail];
[e-mail]
		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: [e-mail]
[mailto:[e-mail]] On 
		> Behalf Of [e-mail] 
		> Sent: 30 July 2005 11:09 
		> To: [e-mail]; [e-mail] 
		> 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: [e-mail] 
		> [mailto:[e-mail]]On Behalf Of 
		> > ext Charles Shen 
		> > Sent: 14 July, 2005 07:45 
		> > To: [e-mail] 
		> > 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 
		> > [e-mail] 
		> > https://www1.ietf.org/mailman/listinfo/nsis 
		> > 
		> 
		> _______________________________________________ 
		> nsis mailing list 
		> [e-mail] 
		> https://www1.ietf.org/mailman/listinfo/nsis 
		> 

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