Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 7 Nov 2003 00:42:39 -0000

hi paulo, jukka,

IMHO we have to consider routing, mobility and multihoming together.
the overlap between any two is (in undefined units, of course) 
about 75%; doing them separately will not help consistency in the
long run.

(and after all, we want this work to feed into protocol design.
we should avoid feeding the protocol designers requirements which are 
similar but subtly different just because they have been developed
independently.)

i do agree that the CT/CARD/pre-reservation issues have to be covered
as part of the same work, for the reasons given below. as i've written 
in another mail, at least partly this is to allow us to make sensible 
consistent decisions about where to optimise (after all, of this work 
is about optimisation).

cheers,

r.

PS I keep seeing stuff saying 'we have to handle tunnels in a special
way when they are used for mobility support'. does anyone have a worked
example of normal tunnel handling failing to work here?

-----Original Message-----
From: Paulo Mendes [mailto:[email-masked]]
Sent: Thursday, November 06, 2003 15:11
To: Jukka MJ Manner
Cc: [email-masked]
Subject: Re: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58

Hi Jukka,

I also agree that something has to be done about the mobility-related drafts, since they have overlapping issues. However, I'm not convinced right now that analyzing mobility, multihoming and routing changes in the draft will lead us to a simpler document, complying with the KISS principle. To start from, because IMO the mobility issue by itself is already very complex, as we tried to show in our analysis draft.
However, I think that we need to start working on the mobility issues that overlap in the presented drafts to achieve the goal of understanding how can NSIS be extended to mobile environments. For instance, I saw that your draft as a more general definition of crossover router.
Hence, I agree with Robert when he says "I think we are talking about here is analysis work which will feed into defining the functionality that is required in the basic NSIS protocols themselves". This is, I agree that we must not include by now any discussion about how to implement any particular solution.

I don't see why shouldn't we work in a mobility analysis draft and a multihoming analysis draft (by nature these are two different things). If after this analysis (divide to conquer principle :)), we realize that a common solution can be achieved, than we should work in a common solution draft. If not, just continue in separate ways.
In what concerns routing changes, if they are due to the movement of end-hosts, this topic is naturally included in the mobility analysis. However, IMO routing changes "in the interior of the network", for instance due to load balancing and link failure, should be considered in the basic NSIS, since they do not happen only in mobile environments.

I tend to disagree with you in what concerns the open issues. If you do not identify open issues by now you will have to do it late. Besides, an efficient solution for mobility within NSIS needs to be aware of open issues if it wants to be the next step in signaling. From the issues mentioned, resource discovery has to do also with the e2e new path and not only with the new access network. Only the latter is done by CARD. In what concerns pre-reservations, you have to deal with this sooner or latter if you want to get good quality levels for multimedia applications while moving. I'm not saying that this is easy or not, or that it should be included in NSIS. I'm just saying that this is an open issue.

In what concerns Minneapolis:
- Agree that the authors of the different drafts should meet in Minneapolis for further discussion (unfortunately I cannot attend this IETF meeting). This discussion should be extended to this mailing list.
- About the presentations, probably it is a little late to get a consensus among authors in order to make a efficient join presentation, but I think that if this could be done, it would be most profitable.

Cheers,
Paulo

Jukka MJ Manner wrote:

Hi,

I basically try to look at things with the KISS principle, and my initial
assumptions are that mobility, routing, and multi-homing have much in
common once we think about them properly and with an open mind. I wouldn't
want to have several different documents discussing NTLP+NSLP and specific
scenarios. Of course, it might happen that we end up realizing that
certain issues are too complex and need their own documents. Still, I
would start with the mentioned issues and see from there.

Regards,
Jukka

On Thu, 6 Nov 2003, Xiaoming Fu wrote:

Hi John, Jukka,

It would be nice that we work together a single document regarding 
mobility and move things on. I also agree that mobility concerns with 
route change and tunneling; is it a little too overloaded for this 
document to cover general routing, multi-homing or general tunnel issues 
as well?

(Unfortunately I will be not able to attend the Minneapolis meeting due 
to personal reasons. However, I am interested in this work and would 
like to participate in the discussions through emails.)

Best regards,
Xiaoming

[email-masked] wrote:
    
Hi Jukka,

The authors of the various mobility drafts listed by John could meet in
Minneapolis, e.g. on Sunday, after the reception, to discuss these issues
before the actual NSIS WG meetings. We could, for example, try to agree on 
an initial set of issues to discuss in the draft, and assign responsible 
section editors, and an overall editor.
        
I fully support this.  If this is acceptable, then the results could
be discussed at the NSIS meeting.  I think this is a much better
use of time, then presenting overlapping individual documents.

Does anyone else have any comments on this?

John

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

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

-- 
Paulo Mendes
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
80687 Munich, Germany
Tel. +49-89-56824-226
Fax. +49-89-56824-300
E-mail: [email-masked]
http://www.docomoeurolabs.de/

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

---

From: "Sung Hycuk Lee" <[email-masked]>
Date: Fri, 7 Nov 2003 15:23:47 +0900

Hi Robert, Paulo, Jukka, and Seong-Ho,

I agree that we should first discuss the analysis of the mobility issues
overlapped 
and newly raised in the submitted drafts at the meeting in Minneapolis as
well as on 
the mailing list, so we could feed into defining the functionality that is
required in the 
basic NSIS protocols.

IMHO, I think that the mobility event detection, state management (refresh
timer), 
interactions with CARD/CT, and pre-reservation issues can be taken into
consideration 
which may be used as references for the NSLP document. Especially,
although 
the pre-reservation related work is an open issue, as Robert, Seong-Ho,
and Paulo mentioned and I've addressed in my previous email since the
Vienna meeting, I also think that the pre-reservation related issue is
important to support seamless services for real-time 
(multimedia) applications (you can see an example related to
CARD/CT/pre-reservation 
in draft-lee-nsis-mobility-nslp-00/01.txt
(http://widecomm.korea.ac.kr/~starsu/draft-lee-nsis-mobility-nslp-01.txt).

I wonder if  the work on a common solution draft is suitable for the NSIS
charter/milestones. 
But  if it is acceptable, I hope that we'll work for a common solution
drat after completing 
the mobility analysis draft. 

Concerning the presentation in Minneapolis, although there may not be
enough time to reach a consensus among authors before the NSIS session, I
also think that it is profitable if the authors can get together on Sunday
and identify the mobility-related common issues and new open issues for
presentation. 

Regards,

Sung-Hyuck

> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Hancock, Robert
> Sent: Friday, November 07, 2003 9:43 AM
> To: Paulo Mendes; Jukka MJ Manner
> Cc: [email-masked]
> Subject: RE: Issues splitting/consensus - Re: [NSIS] Details 
> about NSIS at IETF 58
> 
> 
> hi paulo, jukka,
> 
> I also agree that something has to be done about the 
> mobility-related drafts, since they have overlapping issues. 
> However, I'm not convinced right now that analyzing mobility, 
> multihoming and routing changes in the draft will lead us to a 
> simpler document, complying with the KISS principle. To start 
> from, because IMO the mobility issue by itself is already very 
> complex, as we tried to show in our analysis draft.
> However, I think that we need to start working on the mobility 
> issues that overlap in the presented drafts to achieve the goal 
> of understanding how can NSIS be extended to mobile environments. 
> For instance, I saw that your draft as a more general definition 
> of crossover router.
> Hence, I agree with Robert when he says "I think we are talking 
> about here is analysis work which will feed into defining the 
> functionality that is required in the basic NSIS protocols 
> themselves". This is, I agree that we must not include by now any 
> discussion about how to implement any particular solution.
> 
> I don't see why shouldn't we work in a mobility analysis draft 
> and a multihoming analysis draft (by nature these are two 
> different things). If after this analysis (divide to conquer 
> principle :)), we realize that a common solution can be achieved, 
> than we should work in a common solution draft. If not, just 
> continue in separate ways.
> In what concerns routing changes, if they are due to the movement 
> of end-hosts, this topic is naturally included in the mobility 
> analysis. However, IMO routing changes "in the interior of the 
> network", for instance due to load balancing and link failure, 
> should be considered in the basic NSIS, since they do not happen 
> only in mobile environments.
> 
> I tend to disagree with you in what concerns the open issues. If 
> you do not identify open issues by now you will have to do it 
> late. Besides, an efficient solution for mobility within NSIS 
> needs to be aware of open issues if it wants to be the next step 
> in signaling. From the issues mentioned, resource discovery has 
> to do also with the e2e new path and not only with the new access 
> network. Only the latter is done by CARD. In what concerns 
> pre-reservations, you have to deal with this sooner or latter if 
> you want to get good quality levels for multimedia applications 
> while moving. I'm not saying that this is easy or not, or that it 
> should be included in NSIS. I'm just saying that this is an open issue.
> 
> - Agree that the authors of the different drafts should meet in 
> Minneapolis for further discussion (unfortunately I cannot attend 
> this IETF meeting). This discussion should be extended to this 
> mailing list.
> - About the presentations, probably it is a little late to get a 
> consensus among authors in order to make a efficient join 
> presentation, but I think that if this could be done, it would be 
> most profitable.
> 
> Cheers,
> Paulo
> 
> Jukka MJ Manner wrote:
> 
> Hi,
>

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 07 Nov 2003 09:26:15 +0100

Robert, Paulo, Jukka, and all,

Hancock, Robert wrote:
> about 75%; doing them separately will not help consistency in the long run.

Seeking an accurate corelation factor might go for mathematical models 
:-) I do see the relationship between routing, mobility and multihome is 
incoherent in some sense. However, if we look at IP mobility protocols 
(which is suggested by the current charter), this relationship might be 
less strong as you expected.

- Generally, a soft state signaling protocol needs to react to route 
change and node failures in "best-effort" IP networks (in this sense 
RSVP which precedes NSIS have presented a good way in regards that; 
infrequent route change can be discerned by RSVP/routing interface and 
repaired by local repair anyway).

- Typical IP mobility protocols do not mandate a multi-homed support, 
but suggest this can be an optimal case when the old and new CoAs are at 
  the same still valid for data transmission.

- What is the in the long run - IMHO - is that IP mobility protocols in 
principle change the Internet way of forwarding data by (much more) 
frequent _route change and adding/removal/change of encapsulations_ in 
the middle _in co-located with host IP address change_, which is 
"MUST-be-supported" for IP mobility. This might be the real difficulty 
behind a rational NSIS-mobility interop work.

- I guess NSIS at the first step might want something that is 
interoperable with basic mobility approaches, where we look for

> consistent decisions about where to optimise (after all, of this work 

I also agree that CT/CARD/pre-res. is part of the mobility 
consideration, as this is the useful scenarios in presence of mobility; 
even if something is not mandatory for IP mobility, they can be a long 
run to pursue.

Cheers,
Xiaoming

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 7 Nov 2003 16:47:31 +0800

Hi Xiaming and all,

>   the same still valid for data transmission.

Although multi-homing is not mandated by mobility protocols, it is something
that happens in a moblity event. I guess it falls into the catagory 1) of
John's classification. It is something the NSIS has too support in the
initial solution.

best regards

Cheng

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Xiaoming Fu
> Sent: Friday, November 07, 2003 4:26 PM
> To: Hancock, Robert
> Cc: Paulo Mendes; Jukka MJ Manner; [email-masked]
> > In what concerns routing changes, if they are due to the
> movement of end-hosts, this topic is naturally included in the
> mobility analysis. However, IMO routing changes "in the interior
> of the network", for instance due to load balancing and link
> failure, should be considered in the basic NSIS, since they do
> not happen only in mobile environments.
> >
> > I tend to disagree with you in what concerns the open issues.
> If you do not identify open issues by now you will have to do it
> > - About the presentations, probably it is a little late to get
> a consensus among authors in order to make a efficient join

---

From: "Charles Q. Shen" <[email-masked]>
Date: Fri, 7 Nov 2003 11:38:36 -0500

Hi Xiaoming,

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Xiaoming Fu
...
> > the overlap between any two is (in undefined units, of 
> course) about 
> > 75%; doing them separately will not help consistency in the 
> long run.
> 

Without the need for a strict mathematical model, we can still see a
relationship that IMHO deserves a coherent approach to these three
mechanisms (routing, mobility and multihoming). The most notable
difference among them is probably whether the flow identity has changed.
But whatever is the case, a common result is a changed session path.
This makes it neat to analyze them together, especially when considering
the topology and the downstream/upstream cross-over routers. Even in the
pure route change case, there could still be tricky issues about
identification of the right cross-over router. 

Best regards,

Charles

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 07 Nov 2003 18:11:56 +0100

Charles,

> identification of the right cross-over router. 

I don't know whether a universal flow id is necessary at NTLP level for 
routing of NSIS packets. Essentially, if one node has NTLP state table 
(which can include session ID, Previous NE, Next NE and possibly, src. & 
dest. info. - not necessary details regarding the data flow), it should 
enough for NTLP to route any NSIS packets matching an item in this 
table, if not, discovery component should be able to find out Next NE. 
Identifying a crossover router can be based on a matching of session ID 
as well.

Cheers,
Xiaoming