[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISP scenarios comments
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