RE: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt

[<Mikael.Lind@teliasonera.com>]

See comments inline. 

> Section 4.3.1 has this sentence in the fifth paragraph:
> "Therefore, the use of same process is recommended especially for
> large ISPs intending to deploy, in the short-term, a fully dual-
> stack backbone infrastructure."
> I needed to read it several times. I think it says: "when deploying
> dual-stack in short-term, same process IS-IS is recommended." Maybe
> the sentence could be rephrased slightly to make it easier to read.
> Also, isn't same process IS-IS recommended in general because of
> operational benefits? It is easier to manage one protocol and topology
> than several. The need to run separate processes should be the
exception.

Agreed, I will try to clarify. 

> 
> In section 5.2 it might be useful to explicitly describe the situation
> where a service is limited by ACLs to e.g. customers. When upgrading
> this service to dual-stack, the corresponding IPv6 ACLs should be
> added to avoid exposing the service worldwide. So, I am thinking
> about prefix filtering and "allow all" defaults.

I think this is partially mentioned in 5.5 although nothing is mentioned
about filtering of traffic going to the customer.

> 
> It would be useful to have a "recommendation" section which summarizes
> the missing features, i.e. the items the IETF should work on. That's
> the main purpose of this document, isn't it? I could only identify:
> - STEP/TSP
> - tunneling when dynamic IPv4 addresses are in use
> - authenticating when the customer connection network is shared
> - multi-homing

Might be a good idea, we will look into this. 

/Mikael