Subject: RE: Comments: draft-savola-v6ops-transarch-01.txt

From: [email-masked]
Date: Fri, 07 Nov 2003 01:16:17 +0100

Hi, 
Also see general comments at end...

Specific Comments
-----------------

   However, the big picture of the transition seems not to have been 
   discussed sufficiently.  Therefore, different people have different
   assumptions on the process, which makes planning the transition 
   architecture very difficult: indeed, it seems that there is a lack of 
   architecture in the transition process.

>>
>> might it be useful to discuss these assumptions before moving on to 
>> the architecture...
>>

2.1. General Principles

   General principles which should be carefully considered when
   architecturing the transition include at least:

     o security

     o simplicity

     o robustness

>>
>> How about introducing the idea of service provisioning here,
>> not sure if it would count as a general principle
>>   Services to be deployed
>>   Behaviour/performance expected
>>

2.2.1. Mechanisms, Deployment Models, and Services

   When forming a transition architecture, there are typically different
   building blocks to be used, from different classes, including:

   Mechanisms:
     o Providing IPv6 connectivity
     o Protocol translation
     o Application-specific protocol interoperability (ie. ALG or proxy)

   Deployment models for IP nodes:
     o IPv4-only
     o Dual-stack with only IPv4 connectivity
     o Dual-stack w/ IPv4/6 connectivity
     o Dual-stack with only IPv6 connectivity
     o IPv6-only

   And services:
     o IPv4-only
     o Separate IPv4 and IPv6
     o IPv4/6
     o IPv6-only

>>
>> Might be good to include some more discussion of the 'starting point' of 
>> the transitioning, e.g.  IPv4 w/wo NAT, dual stack (various flavours) or 
>> new (IPv6 only?)
>>

2.3. Transition Mechanism Deployment Considerations

   There are a few very important questions which must be addressed in
   the cases where a transition mechanism deployment is deemed
   necessary.  For example:

     o if I deploy IPv6-only service, whose burden is it to enable its
       use by all clients I wish to make it accessible to?

     o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6
       connectivity, whose burden is it to enable them to access all the
       services they want?

     o how much easier would it be to go for dual-stack approach
       instead?

>>
>> Definitely, I think the idea of discussing responsibility for the 
>> provisioning of transitioning is important...
>>

I think this is a good draft and something that should be discussed here sooner rather than later, however it’s perhaps a bit too general at this stage and doesn't actually specify an architecture as much as put forward some useful guidelines. 

It would be great to get more discussion of the 'assumptions' at the start of the document highlighting the main points of contention/discussion to help provide some clarification.

Another point is that while now it is probably best to deploy dual stack with limited IPv6, it might be an idea to outline how this is likely to change in the future. 

Just some thoughts I had, hope this helps.
Michael

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Nov 2003 01:01:47 +0200 (EET)

Hi,

Thanks for comments.  Sorry for the delay in responding; I'll revise the 
doc based on this (and a couple of other documents) to -03 after the 
meeting.

(Btw, a different quoting style might be easier to follow-up.. :-)

> might it be useful to discuss these assumptions before moving on to 

I think this has improved; a new section has been added before 2.1 already 
in -02 version.

>   Behaviour/performance expected

Hmm.. could you elaborate a bit more?  did you have specific ideas in mind 
how to integrate it to the rest of the document?  That is, what level of 
services you're referring to?  The expected performance etc. in realistic 
terms might also be difficult to estimate..

> the transitioning, e.g.  IPv4 w/wo NAT, dual stack (various flavours) or 

Could you elaborate a bit (please check -02 version btw, this has improved 
as well!)?  There *maybe* could be some brief description without starting 
scenarios, like v4 w/ NAT or v4 w/o NAT, but otherwise I think it has been 
covered..

> provisioning of transitioning is important...

Yep.. I'm not sure how to proceed from there, though.  If you have 
thoughts how to make these issues more concrete (not just questions here 
and there, and discussed a bit here and there) I'm all ears :-)

> I think this is a good draft and something that should be discussed here
> sooner rather than later, however it’s perhaps a bit too general at this
> stage and doesn't actually specify an architecture as much as put
> forward some useful guidelines.

I'm trying to avoid preaching "gospel", giving folks thoughts is more 
important :-)
 
> It would be great to get more discussion of the 'assumptions' at the
> start of the document highlighting the main points of
> contention/discussion to help provide some clarification.

Yep, already there a bit .. see if you agree if it's sufficient or not?
 
> Another point is that while now it is probably best to deploy dual stack
> with limited IPv6, it might be an idea to outline how this is likely to
> change in the future.

True..

Thanks,

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Michael Mackay" <[email-masked]>
Date: Thu, 13 Nov 2003 14:55:01 -0000

Hi,

>I think this has improved; a new section has been added before 2.1
already 

Yup, I agree with 2.1 but it would be good to try to expand on it and
formalise this a bit more, if not here then somewhere. I see this as
potentially being a quite important bit of the draft and while you
certainly can't cover the whole thing in its entirety or present
complete arguments either way, there should be something that makes the
reader aware of a set of the main assumptions of high-level
transitioning deployment. 

>> How about introducing the idea of service provisioning here, not sure

>> if it would count as a general principle
>>   Services to be deployed

Absolutely, it certainly isn't realistic to go into any sort of detail
about the actual performance you can expect but surely the services you
want to deploy over the transitioning architecture would have a
relatively large affect on the architecture you deploy. Both in terms of
'performance' characteristics (bandwidth, scalability, etc) and services
(protocols, etc) you want it to support.
I lumped them together (though they probably should be separate) to
indicate that what you operate over/expect from the architecture would
have a bearing on what you deploy in the architecture itself (and so
should count as a 'principle'?).  

>> Might be good to include some more discussion of the 'starting point'

>> of the transitioning, e.g.  IPv4 w/wo NAT, dual stack (various
flavours) 
>> or new (IPv6 only?)

Ah, sorry about the mix-up. I had the -01 version (that expires April
04) and hadn't seen that -02 was out. That's fine.

>and there, and discussed a bit here and there) I'm all ears :-)

Not sure how to approach this as it's something I think that needs to be
discussed and perhaps some consensus reached on the list.  Other than
emphasising that the impetus right now lies with early adopters (which
you've done) and suggesting how this might pan out in the future... 
dunno :-)
In an ideal world I suppose everyone should be responsible for their own
little bit of the transitioning scope within their boundaries, from
local administrators on their own networks to service providers and
beyond. Defining who should do what and what they should then provide to
their users might be one way to start thinking about it. What do you
think?   

>> I think this is a good draft and something that should be discussed 
>> here sooner rather than later, however it's perhaps a bit too general

>> at this stage and doesn't actually specify an architecture as much as

>> put forward some useful guidelines.
>
 
fair enough.

>> Another point is that while now it is probably best to deploy dual 
>> stack with limited IPv6, it might be an idea to outline how this is 
>> likely to change in the future.
>
>True..

I suppose it really depends upon what you see as the scope for the
draft. I agree with the phases outlined ranging from IPv4 only through
various flavours of dual stack to IPv6 only and the issues raised in
each, but it would be nice to give a clearer idea of the
preconditions/motivators for each phase and as such the prompts for the
next shift along i.e. from dual stack v4/6 to IPv6 only. This might help
readers to understand where we are now and where we are going/when we
can expect to get there.

Sorry about the mix-up, hope this clarifies things a bit.
All the best, 
Michael