Subject: Some ISP Scenarios Comments

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Mar 2003 18:23:01 +0200 (EET)

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

---

From: Bob Fink <[email-masked]>
Date: Sun, 09 Mar 2003 22:50:49 -0800

Pekka,

>In my opinion, the document is about ready to be accepted as a w.g. item.

I have not yet read the -05 version, but the -04 version just outlines the 
IPv4 architecture of various ISP environments without giving any ipv6 
transition scenarioz that are to be attempted/analyzed, i.e., no IPv6 
context was given in the -04 version. Margaret, Itojun and I are not 
willing to have this considered as a wg draft until this is corrected. The 
-05 version may have added some of this, but I haven't reviewed it yet. 
Meanwhile the new lead/editor, Mikael Lind, is aware of our view of this 
and is generating a plan soon to bring the draft to the level we need it.

Thanks for your efforts,

Bob

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Mar 2003 09:03:21 +0200 (EET)

Hi,

On Sun, 9 Mar 2003, Bob Fink wrote:
> context was given in the -04 version. 

There seems to be some confusion (see my comments on Enterprise Scenarios 
and Jim's reply) about what exactly the contents of "Enterprise scenarios" 
should be.  At least on my part..

I was thinking that an "ideal" scenarios document would describe the
scenarios with _IPv4_ (or with a protocol-agnostic way) with as much
detail as possible, which would enable the _Solutions_ document to expand
from there painlessly, to IPv6 situations, mechanisms and solutions.

Of course, some text on IPv6 to scope the work better (non-solutions
centric) might also be OK, but not too much. (3gpp-cases is a good example
here, but may be difficult to compare against as it's quite restricted.)

Perhaps this is something that is is needed to reach common understanding
on?  It should make writing the drafts easier too :-)