[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISP scenarios comments

To: Cleve Mickles <micklesc@aol.net>
Subject: ISP scenarios comments
From: Pekka Savola <pekkas@netcore.fi>
Date: Wed, 18 Sep 2002 18:25:58 +0300 (EEST)
Cc: v6ops@ops.ietf.org
Delivery-date: Wed, 18 Sep 2002 08:27:37 -0700
Envelope-to: v6ops-data@psg.com
Hello,

Some comments (and additional thoughts on missing sections).

 - DSL etc. scenarios need to consider (with coordination of unmanaged
networks scenarios) at least still:
  * should dynamic/static prefixes be used?
     o static make many things (e.g. service registration, less need for DNS
updates, reverse/forward DNS) easier
     o privacy considerations with static /48 prefixes: RFC3041 is pretty
much useless

- currently there is little text except for the DSL case, some issues to
consider (something I quickly write down on the plane) in Core/Backbone 
networks:

 * routing protocol issues
   - same protocol (where applicable) for IPv6 and IPv4 or keep them
separate?
     o same link state database for IS-IS?
     o problem: multi-topology IS-IS would often be needed (if v4/v6
topologies are slightly different, seems probable)
     o IMO: pick a different protocol for IPv6.  We have OSPFv2 for v4 and
IS-IS for v6-only.
   - Which one to pick: OSPFv3, IS-IS or RIPng (ugh..)

 * multicast issues
   - support is yet a bit .. raw or non-existant.
   - there is no MSDP, so there can be only one PIM domain currently
   - should we focus on SSM only

 * transition: how to enable v6
   - v4/v6 dual stack everywhere?
   - tunneling (which kind: configured IP-in-IP, L2 tunneling (hardware
restrictions on e.g. Cisco GSR, ...)
   - existing MPLS networks

 * addressing
   - which kind of addresses to use, prefix lengths?
   - avoid using site-locals

 * long-term plans/transition overview (this could possibly be a more
generic document too)
   - what services could become v6-only soon (or sooner than others) -- and
what would have to be done to make it so?
   - what must have v4 support for a long time yet (e.g. backup MX's, DNS
servers, ...)
     o no need to think of the "exit plan for v4" for these yet, IMO.
   - what should be v6-enabled soon (or sooner than other services .. e.g.
separate v4/v6 www cache service, recursive v4/v6 DNS cache server, ...)
   - what additional services would be nice to have in the ISP network (e.g.
6to4 relay)

- section 2, scope:
  * I don't see why Ethernet _to the home_ is special, generalize?

- section 3.1
  * "Most networks employ some type of traffic engineering.."
    ==> s/Most/Many/ ?
  * s/over provisioning/overprovisioning/?
  * s/authentication( radius or tacacs)/authentication (e.g. radius or tacacs/

- section 3.2
  * spell out "HFC".

- section 3.3.1
  * possibly delete the third paragraph ("The POTS..") -- irrelevant
  * definitely delete everything from there until the "Several models are
used" -- completely irrelevant
  * s/through ATM, Ethernet/through e.g. Ethernet/ -- ATM is IMO a minor
corner case here.

- section 3.3.2.1
  * one should discuss the difference of bridged/routed ATM encapsulation. 
This has significant impact on v6 deployment: with bridged, the xDSL box
does not need to know about v6 at all (cost of v6 deployment is very small)
  * "The NSP edge router sees all subscribers as attached to the same
Ethernet link.."  -- really?  I don't think this was the case; I thought
everyone would have its own sub-interface and would have its own ACL's etc.

- section 3.3.2.2.1
  * spell out IPCP.

- section 3.3.2.2.2 & 3.3.2.3.2
  * extend "customer premises" in the figure a bit more to the right so 
"Modem" will fit in there.

- section 3.3.3
 * s/operates/operate/

- section 3.3.6
 * "edge routers"; do you mean CPE or ISP-located edge routers (just to be
clear)?

- section 5
 * one operational issue is being able to monitor respective v4/v6 traffic
levels in dual-stack interfaces
 * another is that some SNMP tools barf on interfaces that don't have even a
dummy IPv4 address
 

On Fri, 13 Sep 2002, Cleve Mickles wrote:
> Only one section of the draft has been updated.  If 
> any of you have experience with DSL deployments please 
> take a look and send comments to the list or myself.
> 
> Thanks,
> 
> Cleve...
> 
> > -----Original Message-----
> > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> > Behalf Of Internet-Drafts@ietf.org
> > Sent: Friday, September 13, 2002 7:45 AM
> > To: IETF-Announce:
> > Cc: v6ops@ops.ietf.org
> > Subject: I-D ACTION:draft-mickles-v6ops-isp-cases-01.txt
> > 
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > 
> > 
> > 	Title		: Transition Scenarios for ISP Networks
> > 	Author(s)	: C. Mickles
> > 	Filename	: draft-mickles-v6ops-isp-cases-01.txt
> > 	Pages		: 20
> > 	Date		: 2002-9-12
> > 	
> > This document describes the different types of Internet Service
> > Provider (ISP) networks in existence today.  It will provide design
> > and operational considerations in delivering network services to
> > customers for five specific areas in an effort to better identify
> > specific issues which may arise during a transition to IPv6.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-01.txt
> > 
> > To remove yourself from the IETF Announcement list, send a message to 
> > ietf-announce-request with the word unsubscribe in the body of 
> > the message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with 
> > the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-mickles-v6ops-isp-cases-01.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE /internet-drafts/draft-mickles-v6ops-isp-cases-01.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > 
> 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
Prev by Date: Re: renumbering
Next by Date: memo, 1st day AM
Previous by thread: RE: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt
Next by thread: Re: ISP scenarios comments
Index(es):
- Date
- Thread