Subject: RE: Some ISP Scenarios Comments

From: <[email-masked]>
Date: Mon, 10 Mar 2003 10:50:34 +0100

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:[email-masked]]
> Sent: den 9 mars 2003 17:23
> To: [email-masked]
> 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
> 
> 
> 
>