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

From: [email-masked]
Date: Fri, 7 Nov 2003 10:13:08 +0200

Hi all,

Just a point of procedure.  Currently, NSIS does not have an explicit charter
item about handling mobility.  The charter does discuss mobility to some
extent, and it is assumed that the NSIS work needs to be mobility friendly.
However, if you are interested in going beyond that, we will need to get
approval for this from our ADs.

Ultimately, I'd like to split mobility into two pieces:

1) Ensuring mobility does not break the NSLPs & NTLP.  This means that our
   initial solution may not be completely optimized for mobility, but
   it won't break in the presence of mobility.

2) Longer term mobility optimization & support.  This would be a possible new
   item for NSIS to consider, which would explicitly deal with how we could
   deal with mobility extentions, etc.  This work is currently outside of the
   charter, but if there is enough support in the WG, it is possible to ask
   for an extension to the NSIS charter to handle this.

What I am looking for at the Minneapolis meeting is to have a general discussion
along the lines of the 2 points above and gage if there is interest in this work.
If there is, then I'd suggest that the interested parties get together after
Minneapolis and work out a combined analysis/discussion/approach  wrt to mobilty
submit and individual submission.  After this is done, we can see if extending
the charter would be reasonable or not.

Please note that the NTLP, NSLP protocols are already underway so I don't want
to insert a new dependency on completing these protocols.

thanks,
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Paulo Mendes
Sent: 06 November, 2003 17: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: Xiaoming Fu <[email-masked]>
Date: Fri, 07 Nov 2003 09:28:08 +0100

John,

I fully agree with your suggestion.

Cheers,
Xiaoming

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 8 Nov 2003 12:22:29 +0100

Hi John

Mobility is handled in other IETF working groups.
I think that this WG should not try to find mobility solutions, but indeed
it should look to ways of how the NSIS protocols
could interoperate with existing (under development by other working groups)
mobility approaches.

Best Regards,
Georgios

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 07, 2003 9:13 AM
Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at
IETF 58

> 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.

---

From: Roland Bless <[email-masked]>
Date: Sun, 9 Nov 2003 19:28:26 +0100

Hi John,

>    for an extension to the NSIS charter to handle this.

Both points sound very reasonable, IMHO. While there is a whole bunch of
optimizations possible, ensuring that things will not break should be 
easier.

> to insert a new dependency on completing these protocols.

Sure, however, mobility issues should be considered to the necessary extent you 
mentioned in 1).

Regards,
 Roland