headers
Jari Arkko | 1 Mar 2005 09:07

Agenda for MOBIKE at IETF-62

This is the preliminary agenda for next week. Comments,
corrections, and other suggestions welcome:

MONDAY, March 7, 2005
0900-1130 Morning Sessions
SEC  mobike     IKEv2 Mobility and Multihoming WG

1. Preliminaries, chairs (10 mins)
   - Notes takers
   - Agenda bashing
   - Document status

2. Design document issues, Hannes Tschofenig (90 mins)
   - Discuss open issues, attempt to come to
     a common understanding on sufficient requirements
     and solutions to move forward

3. Protocol proposals update, TBD (30 mins)
   - Update on existing individual drafts and how
     they measure against the current design document
   - Slot reserved for spreading information and
     making the protocol design more concrete, not
     for fine tuning the specific documents
Permalink | Reply | 1 comment |
headers
Pasi.Eronen | 3 Mar 2005 20:12
Picon

Thoughts about issues 10/19: changing address vs. paths, and so on...

Hi all,

The recent discussions about issue #19 (same addresses for both
directions?) lead me to do some thinking about different ways
the tunnel header addresses for IPsec SAs can be chosen.

It seems that there are a couple of quite different approaches
to this (and some variations of those)... and I also have the
feeling that some of the text in the design draft and protocol
proposals has implicitly assumed one of these without really
making the assumption explicit.

Below I've gone through some of the approaches I've identified
so far, but there probably are others that make sense as well.

These aspects are also related to issue #17 (partial/full
connectivity)

-----

Option 1: "MOBIKE just informs the peer of our addresses; how 
they get used is a matter of local policy beyond our scope."

This would be the approach closest to SCTP, I think (and quite
close to the approach in Francis's and Tero's protocol
proposals, I think). The basic operation here would be as
follows: Host A sends a list of its addresses to B (and when the
list changes, sends either a new list or diffs to the previous
one).  And vice versa for B.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jari Arkko | 3 Mar 2005 20:25

Re: Thoughts about issues 10/19: changing address vs. paths, and so on...

Pasi.Eronen <at> nokia.com wrote:

>Hi all,
>
>The recent discussions about issue #19 (same addresses for both
>directions?) lead me to do some thinking about different ways
>the tunnel header addresses for IPsec SAs can be chosen.
>
>It seems that there are a couple of quite different approaches
>to this (and some variations of those)... and I also have the
>feeling that some of the text in the design draft and protocol
>proposals has implicitly assumed one of these without really
>making the assumption explicit.
>
>Below I've gone through some of the approaches I've identified
>so far, but there probably are others that make sense as well.
>
>These aspects are also related to issue #17 (partial/full
>connectivity)
>
>-----
>
>Option 1: "MOBIKE just informs the peer of our addresses; how 
>they get used is a matter of local policy beyond our scope."
>
>This would be the approach closest to SCTP, I think (and quite
>close to the approach in Francis's and Tero's protocol
>proposals, I think). The basic operation here would be as
>follows: Host A sends a list of its addresses to B (and when the
>list changes, sends either a new list or diffs to the previous
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Kempf | 4 Mar 2005 18:21

Re: Design draft role, implementation requirements (Was: latest draft snapshot)

I agree. I think the framework document should be sufficiently clear that a
separate requirements document isn't necessary. As I understand it, the
point of the framework document was to achieve some kind of concensus on the
basic architecture. I think that should be sufficient.

            jak

----- Original Message ----- 
From: "Jari Arkko" <jari.arkko <at> piuha.net>
To: <bora <at> cisco.com>; "Tschofenig Hannes" <hannes.tschofenig <at> siemens.com>
Cc: <mobike <at> machshav.com>
Sent: Friday, March 04, 2005 7:59 AM
Subject: [Mobike] Design draft role, implementation requirements (Was:
latest draft snapshot)

> >
> >
> >>/ > In general, I think rename this draft to be "Framework for MOBIKE."
> >/>/ > Then do a requirements draft that has as little text as possible.
> >/>/
> >/>/  i hope that we do not need a requirements draft since we
> >/>/ already came quite far and are hopefully finished with the
> >/>/ work in mobike. making progress would be a good thing.
> >/
> >Well, I think the WG has a choice on this, I think this document is
> >suitable as a framework document, for requirements, I think we need
> >a more terse and succint document just pointing out what the
implementation
> >needs to do. That is of course my opinion.
> >
(Continue reading)

Permalink | Reply | 835 comments |
headers
James Kempf | 4 Mar 2005 18:49

Re: Design draft role, implementation requirements (Was: latest draft snapshot)


> I am fine with that, the problem is that this framework document
> is not sufficiently concise in the requirements area
> so that I can go ahead and write code off of.
>

A framework document isn't ever sufficiently concise to write code off of.
It should be sufficiently concise to guide the design of the protocol, which
should be sufficiently precise to write code off of. Or, at least, that is
my understanding of the usual relationship between framework documents and
code design (i.e. Proposed Standard) documents.

            jak
Permalink | Reply | 3 comments |
headers
Bora Akyol | 4 Mar 2005 18:50
Picon
Favicon

RE: Design draft role, implementation requirements (Was: latest draft snapshot)

Do you disagree with putting a summary of requirements section
somewhere in the framework? 

If you do disagree, why?

Bora 

> -----Original Message-----
> From: James Kempf [mailto:kempf <at> docomolabs-usa.com] 
> Sent: Friday, March 04, 2005 9:50 AM
> To: Bora Akyol; 'Jari Arkko'; 'Tschofenig Hannes'
> Cc: mobike <at> machshav.com
> Subject: Re: [Mobike] Design draft role, implementation 
> requirements (Was: latest draft snapshot)
> 
> 
> > I am fine with that, the problem is that this framework document is 
> > not sufficiently concise in the requirements area so that I can go 
> > ahead and write code off of.
> >
> 
> A framework document isn't ever sufficiently concise to write 
> code off of.
> It should be sufficiently concise to guide the design of the 
> protocol, which should be sufficiently precise to write code 
> off of. Or, at least, that is my understanding of the usual 
> relationship between framework documents and code design 
> (i.e. Proposed Standard) documents.
> 
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Kempf | 4 Mar 2005 18:59

Re: Design draft role, implementation requirements (Was: latest draft snapshot)

No, that's fine. The document needs to be concise as to what is required of
the protocol, and the architecture.

I was just commenting on what seemed to be an assumption in your email that
the document was intended to be the protocol design, rather than to guide
it, unless the intent of the WG in this case is to not abide by that
customary relationship.

            jak

----- Original Message ----- 
From: "Bora Akyol" <bora <at> cisco.com>
To: "'James Kempf'" <kempf <at> docomolabs-usa.com>; "'Jari Arkko'"
<jari.arkko <at> piuha.net>; "'Tschofenig Hannes'"
<hannes.tschofenig <at> siemens.com>
Cc: <mobike <at> machshav.com>
Sent: Friday, March 04, 2005 9:50 AM
Subject: RE: [Mobike] Design draft role, implementation requirements (Was:
latest draft snapshot)

> Do you disagree with putting a summary of requirements section
> somewhere in the framework?
>
> If you do disagree, why?
>
> Bora
>
> > -----Original Message-----
> > From: James Kempf [mailto:kempf <at> docomolabs-usa.com]
> > Sent: Friday, March 04, 2005 9:50 AM
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bora Akyol | 4 Mar 2005 19:00
Picon
Favicon

RE: Design draft role, implementation requirements (Was: latest draft snapshot)

Thanks, I did not mean to imply that this document should be the design of
the protocol,
just that it would be nice to have a summary of the requirements in this
doc.

Bora

> -----Original Message-----
> From: James Kempf [mailto:kempf <at> docomolabs-usa.com] 
> Sent: Friday, March 04, 2005 9:59 AM
> To: Bora Akyol; 'Jari Arkko'; 'Tschofenig Hannes'
> Cc: mobike <at> machshav.com
> Subject: Re: [Mobike] Design draft role, implementation 
> requirements (Was: latest draft snapshot)
> 
> No, that's fine. The document needs to be concise as to what 
> is required of the protocol, and the architecture.
> 
> I was just commenting on what seemed to be an assumption in 
> your email that the document was intended to be the protocol 
> design, rather than to guide it, unless the intent of the WG 
> in this case is to not abide by that customary relationship.
> 
>             jak
> 
> ----- Original Message -----
> From: "Bora Akyol" <bora <at> cisco.com>
> To: "'James Kempf'" <kempf <at> docomolabs-usa.com>; "'Jari Arkko'"
> <jari.arkko <at> piuha.net>; "'Tschofenig Hannes'"
> <hannes.tschofenig <at> siemens.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jari Arkko | 4 Mar 2005 19:20

Re: Thoughts about issues 10/19: changing address vs. paths, and so on...


Thinking some more about this, I would actually like
to go for approach #3. This would simplify our protocol,
and would ensure an arhitecture where NAT and
firewall traversal can happen easily.

If make this decision, it seems that the following other
open issues would also be solved:

1 (direct or indirect indicators): Because one side is
responsible for the whole thing, we would have to
support failure detection using DPD at the initiator
side. Note that responder may still need to update its
own list of addresses now and then, say if an interface
goes down.

unassigned issue # (the list complaint that large SGWs
should not be forced to check the connectivity to clients):
The client would be doing all the work.

--Jari
Permalink | Reply | 0 comments |
headers
Jari Arkko | 4 Mar 2005 19:20

Re: Design draft role, implementation requirements (Was: latest draft snapshot)

Bora Akyol wrote:

>I am fine with that, the problem is that this framework document
>is not sufficiently concise in the requirements area
>so that I can go ahead and write code off of.
>  
>
Yes. We are not there yet, its in the future protocol doc!

>Specifically, it is hard to judge from this document, what is a MUST,
>what is a SHOULD, and what is purely optional and esoteric.
>
>Maybe we can add a final section to the document summarizing the
>requirements, I would be happy to contribute to that.
>  
>
Thanks for offering to contribute! I can see two potential
items where additional contributions like this would be useful:

- A summary table at the end of the design document that
  lists the design choices and features that are needed.
  This is just a list or a table; not something that you can
  write code from. But it could help people grasp easier
  what conclusions the document has reached. Something
  like:

      - Indicating support for MOBIKE: Use FOO feature from IKEv2.
      - Storing peer addresses: Store multiple, not just one
      - ...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane