[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Some ISP Scenarios Comments
Hi,
A complete revision of the document is underway. Since the current
version doesn't cover IPv6 in any extent we have considered a completely
new structure that will put more emphasis on different scenarios for
IPv6 introduction instead of on the existing network structure. Although
a new document is underway your comment will be useful, thank you for
your extensive review.
/Mikael Lind
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: den 9 mars 2003 17:23
> To: v6ops@ops.ietf.org
> Subject: Some ISP Scenarios Comments
>
> Hi,
>
> I quickly re-read the ISP scenarios document, the previous version,
-04.
> I think most comments are probably applicable, as changes happened
mainly
> to the ISP section.
>
> In my opinion, the document is about ready to be accepted as a w.g.
item.
>
> There is a big editorial choice ahead, IMO, which is whether some
"Access
> Networks" specific stuff (about everything except under core/backbone
and
> IXP sections) should be "aggregated" somewhere. That is, there seems
to
> be no use repeating the same thing 5 times (e.g. about user
> authentication, access routers, hosting gear, web caching
infrastructure
> etc.etc.), and only report the connectivity-specific stuff under the
> appropriate sections.
>
> Comments below.
>
> Substantial:
> ------------
> Status of this Memo
> This document is an Internet-Draft and is subject to all
> Provisions of Section 10 of RFC2026. Internet-Drafts are working
> documents of the Internet Engineering Task Force (IETF), its
> areas, and its working groups. Note that other groups may also
>
> ==> Here and elsewhere: the editorial quality and conformance to
typical
> format must improve. For example, in a lot of places, paragraphs
should
> be separated by empty lines, etc. Doing that makes reading the doc *a
> lot* easier.
>
> ==> I will make some direct contributions, if no one else comes first,
> when the situation has improved.
>
> ___|___ ___|__ ___|___
> | | | | | |
> | CPE1 | | CPE2 | | CPE(n)|
> |_______| |______| |_______|
>
>
> ==> These should be named "Customer1", .. (n). Also in this section,
> issues about CPE's etc. should really be split off: such should be
dealt
> under the appropriate access network scenarios section.
>
> ==> I'm not certain how to best handle the generic "layer" between all
the
> access methods: there are certainly a lot of common elements, does
> everything have to be repeated N times? That's something which one
may
> have to consider (e.g. whether to create "Access Networks" abstraction
> layer explaining the generic stuff)
>
> 4.1 Topology
>
> ==> This, and some scenarios above, are too "core/edge" -separation
> centric. There are a lot of networks which only include bigger and
> smaller edge devices, some of which are more geared to "core-like"
> operation while others are not. One such "all edge" network, for
example,
> is GEANT (http://www.geant.net/geant/about-geant.html).
>
> 4.3.2 EGP
> Generally BGP4 is the Edge gateway protocol of choice. The EGP
> routing table consists of networks, which are received via
> customer advertisements, statically configured for customers who
> are not running a dynamic routing protocol or networks that are
> nailed up as part of the ISP infrastructure.
>
> ==> It is also common practise to redistribute static routes, through
> safety checks of a route map. This is particularly enticing if the
> customer routes are part of larger aggregates, that is, even if the
> customer link flaps, no BGP updates/withdrawals are propagated to the
> Internet, only to the internal topology of the ISP.
>
> 4.3.4 Multicast
> PIM-SM is the generally accepted solution for deploying multicast.
>
> ==> a lot of stuff should be added here in the future, on PIM, MBGP,
MSDP,
> RP's, BSR, whether customers use your RP, etc.etc. I could contribute
> something even.
>
> 4.5. Security
>
> ==> protecting routers (e.g. access lists that prevent telnet/ssh
access,
> other methods, account management, etc.) should be described.
>
> 4.5.1 Intrusion Detection
> Intrusion detection mechanisms and systems are used to protect
> infrastructure and host gear. Generally these intrusion
> detection systems are placed at various points within the network
> to search for vulnerabilities within the infrastructure as well
> as monitor activity that may be considered suspicious.
>
> ==> what infrastructure you're talking about? Certainly, I think it's
> quite rare to see IDS systems deployed to protect routers. They're
more
> of protecting the management systems which are used to control the
> network, if anything.
>
> 4.5.2 Ingress Filtering
> Ingress filtering on CORE networks comes in multiple flavors.
> For providers that do filter, the first level is EGP filtering.
> When a peering session is setup, ISPs require a peer to register
> their routes in an IRR and that data is used to create an EGP
> filter on the peering session to only accept registered
> advertised routes.
>
> ==> there are also manually configured access lists, e.g. lists that
> disallow any more specifics from your aggregates (inbound or
outbound).
> Of course, with todays errant multihoming practises, this may not be
> possible for some ISP's.
>
> ==> speaking of which, one should probably spend some time describing
> mechanisms which are used for multihoming the backbone network
(trivial)
> and multihoming the customers (more related to access networks).
>
>
> Customer Premises NAP NSP
> <-------------------------> <---------------> <-------------------->
>
> +-----+ +-------+ +-----+ +--------+ +-----------+
> |Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ ISP | ISP
> +-----+ +-------+ |Modem| +--------+ | Edge +==>
Network
> +-----+ | Router |
> +-----------+
> <---------------------------->
> ATM
>
> Customer Premises NAP NSP
> <--------------------> <----------------------> <----------------->
>
> +-----------+
> | AAA |
> +-------+ Radius |
> | | TACACS |
> | +-----------+
> |
> +-----+ +-------+ +--------+ +----+-----+ +-----------+
> |Hosts|--+Router +------+ DSLAM +-+ BAS +-+ ISP |
> +-----+ +-------+ +--------+ +----------+ | Edge +=>Core
> | Router |
> +-----------+
> <-------------------------->
> PPP
>
> ==> some DSL figures include DSL model while others don't. Sync that
up.
> (Note: I've mentioned this before, too, I'm getting tired of repeating
> myself.)
>
> 7.2. Hardware
> The hardware involved in dialup service provider connections
> include the CPE device that is usually a 56K modem, the Terminal
> server/modem bank and an authentication server.
>
> ==> also in some other places, I believe "narrowband" also applies to
ISDN
> connections.
>
> +----------+ +-------+
> | IP | | IP |
> +----------+ +-----------+ +-------+
> | Wireless | | Bridging | | | |
> | LAN | +-----------+ | X | Y |
> | | |WLAN | X | | | |
> +----------+ +-----+-----+ +---+---+
>
> ==> the model of WLAN section seems to build on the fact that AP acts
as a
> bridge. This is not necessarily the case. AP can also be a router
(when
> AP and router are co-located).
>
> 8.4 Security
>
> ==> Note that even 801.11x with extensions does not give protection;
there
> is always the issue of a host and AP being certain that they are in
fact
> talking to each other (a man-in-the-middle attack). Not sure if this
> needs to said in the draft (and this is why why some e.g. force the
use of
> VPNs usings IPsec in WLAN's, even though this is not typical in
> hotspot-like activities)
>
> An IX is based on a layer 2 infrastructure that can be, either
> local to given building, or distributed over a large are by the
> way multiple interconnected point of presence. This layer 2
>
> ==> note that there are also Layer-3 exchanges (the same applies to
IPv4
> -- there is zero differences there)
>
> ==> another issue to describe is how, in a L2 model, connections are
> established: ie, one big L2 mesh, or e.g. point-to-point L2 (e.g.
through
> peer-to-peer VLAN's or ATM PVC's).
>
> ==> an issue to note is that in some L2 systems, multicast and/or IPv6
are
> separated in different VLAN's and PVC's. (This has some advantageous
> consequences.)
>
> 10.1.1 Hardware
>
> Basically, a regular IX is based on a layer 2 switch, or set of
> layer 2 switches that may either local to a building, or
> distributed over larger area. It provides also room space and
> power supply to enable long haul providers to install their own
> routers and to exchange routes to each other according to a
> peering agreement.
>
> ==> the last sentence is not correct: IX's are in no way forced to
provide
> any room space or supply for routers. In many cases, they don't.
> Providers connect to the IX using a circuit, which is hooked up to the
L2
> fabric.
>
> Semi/Editorial:
> ---------------
>
> The local border routers are
> route reflector clients of the core.
>
> ==> add "often" or "sometimes" here, this is by far not always the
case
>
> In some cases CPE equipment is provided by the
> CORE ISP.
>
> ==> irrelevant in the context of core/backbone networks.
>
> Customer routes are pinned up on core routers.
>
> ==> I'm not sure what you're trying to say; please use a bit more
formal
> language, same under Aggregation and elsewhere.
>
> 5.3.2 CMTS Layer-2 Bridge
>
> IPv6 is then deployed on the ISP router infrastructure natively
> or using an automatic tunneling scheme like 6to4[RFC3056].
>
> ==> move this kind of text to the solutions document.
>
> In an ideal world every IPv4 NAT router would be upgraded to
> additionally become a native IPv6 router using 6to4 automatic
> tunneling.
> In general 6to4 residential gateway devices must be made as
> self-configuring as existing IPv4 NAT routers.
>
> ==> likewise.
>
> If the CMTS is a
> native IPv6 router then it will likely need to participate in
> ISPs the IGP of choice. If the CMTS is a bridge, the
> infrastructure router(s) that it connects to will need to speak
> an IGP. If 6to4[RFC3056] is used, it is recommended that the ISP
> sink (and forward) traffic to the anycast 6to4 relay router address
> [RFC3068].
>
> ==> such as above, talk more of _IPv4_ scenarios!
>
> Existing IPv4 filter
> software will not block IPv6 communication. If IPv6 is tunneled
> over an IPv4 infrastructure filters may need to examine the
> contents of encapsulated packets.
>
> ==> likewise.
>
> 5.8 Host Gear
>
> Dual stack DNS server is necessary if you want to support
> IPv6-only CPE equipment.
> DDNS is pretty much mandatory if you want to give CPE devices DNS
> names. This is because only the IPv6 host knows what its full
> IPv6 address is (esp when privacy addresses are used).
> Transition functionality.. which? where?
> v4/v6 translation between devices in the home is done where? If
> RFC1918 addresses are in use (perhaps behind the NAT), then there
> isn't much choice but to do it inside the CPE box.
> Transparent proxy caches aren't going to cache IPv6 web traffic.
>
> ==> talk about v4, not about v6. Almost all of this should go to the
> solutions doc.
>
> Customer Premises | Network Access Provider | Network Service Provider
> CP NAP NSP
>
> +-----+ +-----+ +-----+
> |Hosts|--| DSL +-------+DSLAM|
> +-----+ |Modem| | +----+
> +-----+ +-----+ |
> |
> +-----+ +------+ | +-----+ +-------+
> |Hosts|--|Router| +--+ BAS +----+ ISP | ISP
> +-----+ +--+---+ +--+ | | Edge +===> Network
> | | +-----+ | Router|
> +--+--+ | +-------+
> | DSL +---+ |
> |Modem| | |
> +-----+ | |
> | +-----+ |
> +-----+ +------+ +---+DSLAM+----+
> |Hosts|--|Router| +---+ |
> +-----+ +--+---+ | +-----+
> | |
> +--+--+ |
> | DSL +---+
> |Modem|
> +-----+
>
>
> ==> I'd replace the last one with the scenario where a host is
directly
> attached to the DSLAM, through a DSL PCI/ISA card. This changes
certain
> assumptions slightly.
>
> (Broadband Access Server = DSLAM aggregator), which is in charge
> of directing them to the POP (Point Of Presence = the ISP Edge
>
> ==> I'd rather see that the term "POP" (here and later) would not be
used
> in this context. We're mixing layers here. PoP is a layer 1 term
> (physical location and place of the connection, where the eqipment
is),
> not layer 2 or 3.
>
> Figure 6.2.2.2
>
> ==> this figure is identical to 6.2.2.1, we can very well live with
just
> one of them, thanks -- same in other a few other figures :-)
>
> addresses today. Customers are usually disconnected every day
>
> ==> "often" or "sometimes" rather than "usually"
>
> IRR
> routing policy is generally registered by the ISP or NSP but in
> some cases the dialup provider may register policy.
>
> ==> it's not probably obvious to all readers what you mean so that
should
> be expanded a bit.
>
> 9.3 Routing
> IGP
> The interior routing for Ethernet access doesn't differ to any
> other routing used with in one particular ISP.
> The routing protocols normally used are IS-IS or OSPF.
>
> EGP
> BGP is used for exchanging external routes.
> Exterior routing is not used towards the end customers since the
> customer networks are seen as being directly connected to the
> edge router and not having a CPE router in between. This means
> that the customer network is routed directly to an interface on
> the edge router and not to a customer router.
>
> ==> under broadband ethernet, a shorter explanation why IGP/EGP does
not
> apply would probably be just as good.
>
> An IPv6 IX, unlike current NAPs, may assign independent long-haul
> provider addresses, according to [RFC2374]. An organization
> subscribing such addresses will be able to change long-haul
> provider without having to renumber.
>
> ==> solutions category (note that this text is mostly outdated anyway,
as
> 2374 is getting historic)
>
> According to [RFC2374] aggreatable addresses are organized into a
> three level hierarchy. IXs, together with long haul providers,
> belong the higher one called "Public Topology". IXs will allocate
> IPv6 addresses to its directly connected subscribers, providing
> them addressing independence from long haul providers. IX will
> then have to include layer 3 functions, e.g. by the means of a
> router, in order to exchange routes with long haul provider, for
> gaining global connectivity to its subscribers. The figure below,
> describes such a new type of IX introducing layer 3 functions,
> and that topology differs from regular IPv4 IX.
>
> ==> ditto (some bits could maybe be left here)
> ==> figure 10.1b can probably also go.
>
> In the case of an IX providing independent addresses to its
> directly connected subscribers, the needed layer 3 function will
> be based on a regular IPv6 router.
>
> ==> same here.
>
> REFERENCES
> [01] TR-025 Core Network Architecture for Access to Legacy Data
> Networks over ADSL, TR-025 - ADSL Forum, September 1999
>
> [02] RFC 1661 The Point-to-Point Protocol (PPP)
>
> ==> split the references and add them in the proper format.
>
>
> Editorial:
> ----------
>
> This section describes the general topologies of and
> characteristics of today's CORE networks. Although there are
>
> ==> s/topologies of/topologies/
>
> aggregation of long haul circuits to remote sites. The
>
> ==> s/haul /haul /
>
> Loopback interfaces and point-to-point links are what make up
> routes within the IGP.
>
> ==> s/are what make up routes/make up the routes/
>
> peers. In the case of customer connections, there are peer
> groups that are configured to send FULL_ROUTES, CUSTOMER-ROUTES
> or DEFAULT-ROUTES to a particular set of customers. To perform
>
> ==> any particular reason to put these in uppercase?
>
> routed connection. Cacheing infrastructure is deployed in CORE
>
> ==> s/Cacheing/Caching/
>
> router. It is usually connected between the cable modem and all
> other CPE equipment allows multiple devices to share a single
>
> ==> s/allows/allowing/
>
> configuration overhead. The NAT/DHCP router is a directional
> IPv4-only device in the communication path between the CMTS and
> the CPE.
>
> ==> "directional" ? I can only try to guess what you mean, reword.
>
> CPE NAT boxes are rectifying routers. This can be viewed as an
> implementation of an "outgoing only" security policy.
>
> ==> likewise with "rectifying".
>
> ToD [RFC0868] for initial time synchronization.
>
> ==> "ToD" is an unknown abbreviation for me, don't use it.
>
> Various MIBs for RF and CPE filter configuration.. DOCSIS OSSI
>
> ==> same for "RF".
>
> 6. Broadband DSL Networks
>
> This section describes the infrastructure that exists in todays
> High Speed DSL Networks.
>
> ==> s/todays/today's/
>
> The hosts are connected to the DSL network either directly
> through a modem, either through a router and a modem.
>
> ==> reword at least the second line, I'm having trouble parsing it.
>
> opened to each NSP, but several PVCs are sometimes used when the
> NSP offers differentiated services (QoS...).
>
> ==> reword the last line to better integrate QoS if a referral to it
is
> necessary.
>
> results in a decrease of the MSS of TCP that applications should
>
> ==> MSS needs to be spelled out.
>
> 6.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL
>
> ==> all the headings need to be in a proper format, in this case:
>
> L2TP Access Aggregation (LAA) Model
>
> presence, via a L2TP tunnel. When a CPE initiates a session with
>
> ==> is it "an L2TP" or "a L2TP"? Typically if you pronounce that,
you'd
> say "an el-two-tee-pee", but I guess putting "a" as for the written
form
> would also be ok.
>
> and are given a new address each time they reconnect. Most of
> the times,
>
> ==> s/times/time/
>
> majority of internet users use today to get online. The
> scenarios will include solutions where the dial infrastructure is
> controlled by one entity as well as solutions where ISPs lease
> modems from a wholesale modem providers.
>
> ==> s/a wholesale/wholesale/, or some other rewording.
>
> made the user credentials are sent to the Authentication server.
>
> ==> s/A/a/
>
> (IEEE 802.11) and 11 Mbps (IEEE 802.11b) to 54 Mbps
> (IEEE 802.11a).
>
> ==> a lot of other stds also give (theoretical) 54 Mbps as you know --
> perhaps change: s/IEEE 801.11a/IEEE 801.11a and others/.
>
> mechanisms are presented in 3.x.5 in detail. Once the host is
> authenticated, AP acts as a bridge in order to relay host's
> information to ISP or vice versa. Various access network
> technologies can be used between AP and ISP. Lease line, xDSL
>
> ==> 3.x.5 ??
> ==> s/Lease/Leased/
>
> ISPs supply not static addresses by default but
> dynamic addresses by DHCP.
>
> ==> reword this completely.
>
> they reconnect. Most of the times, customers use private
>
> ==> s/times/time/
>
> ISPs may need to configure traffic filtering or provisioning on
> demand of their customers.
>
> ==> reword
>
> Like ethernet, IEEE 802.11 standard dose not define
> authentication and security mechanisms.
>
> ==> s/eth/Eth/
> ==> s/dose/does/
>
> Moreover, WLAN is
> basically a broadcast network and each host can listen
> information of another host within the same AP service area.
>
> ==> reword the last two lines, especially "listen information of
another
> host"..
>
> This mechanism supports host that does not support IEEE 802.1x.
>
> ==> s/host that does/hosts that do/
>
> Therefore, very complicated data privacy mechanism must
> be provided in order not to be revealed by other hosts except
> intended host.
>
> ==> reword from "releveled..."
>
> 9.1. Topology
> Physical
> The layouts of Ethernet based accesses to the home are all almost
> identical. They usually consist in a star topology terminated in
>
> ==> different formatting with subtitles, please.
> ==> s/consist in/consist of/
>
> some cases used. It can consist of web login or PPPoE. Web login
> can be done in two ways, one time login where the device's MAC-
> address is registered and kept or session login where login is
>
> ==> s/one time/as one time/
> ==> s/session login/as session login/
>
> local to given building, or distributed over a large are by the
> way multiple interconnected point of presence. This layer 2
> infrastructure enables players (e.g. long haul providers)
>
> ==> s/are by the way/area in/
> ==> s/presence/precences/
> ==> use a more formal&better term than "player". :-)
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>
>