Subject: I-D ACTION:draft-mickles-v6ops-isp-cases-01.txt

From: [email-masked]
Date: Fri, 13 Sep 2002 07:44:32 -0400

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:
	[email-masked].
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.

---

From: "Cleve Mickles" <[email-masked]>
Date: Fri, 13 Sep 2002 14:54:51 -0400

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: Friday, September 13, 2002 7:45 AM
> To: IETF-Announce:
> Cc: [email-masked]
> Subject: I-D ACTION:draft-mickles-v6ops-isp-cases-01.txt
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Sep 2002 18:25:58 +0300 (EEST)

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

-- 
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

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 18 Sep 2002 15:04:14 -0400

proposed modification to draft-ietf-ngtrans-ipv4survey-02.txt

<currenttext>
3.12 RFC 1305 Network Time Protocol (Version 3)
...
There are numerous places in sample code and algorithms use the above
mentioned variables.  It seems that there is no reason to modify the
actual protocol.  A small number of text changes and an update to
implementations to understand both IPv4 and IPv6 addresses can achieve
an NTP that works on both network layer protocols.
</currenttext>

my colleague Jean-Francois did the port. There is a problem which is the 
refid. Without changes, NTPv6 does not scale well without a fix.

Here is a suggested text to replace the quoted text to this draft section:

<newtext>
The refid field identifies uniquely the reference clock a ntp is based on. 
This refid is a 32-bit field in the NTP packet. So it cannot carry an IPv6 
address without a protocol change. The discussions in the ntp dev team and 
ntp author around how to resolve this issue went to put a "compressed" ipv6 
address in this refid field. This in fact changes the current protocol.

Other than the refid change, there is no other changes needed to support 
IPv6 in NTP.
</newtext>

------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Sep 2002 22:40:34 +0300 (EEST)

> Other than the refid change, there is no other changes needed to support 

Some reference to that change (to use a hash of a part of the address, I 
recall) should be there too.  Is there other than the expired I-D?  Has 
the change in the protocol been ratified or in the process of being done 
so?

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 18 Sep 2002 16:16:42 -0400

-- mercredi, septembre 18, 2002 22:40:34 +0300 Pekka Savola 
<[email-masked]> wrote/a écrit:

>> The refid field identifies uniquely the reference clock a ntp is based
>> on.  This refid is a 32-bit field in the NTP packet. So it cannot carry
>> an IPv6  address without a protocol change. The discussions in the ntp
>> dev team and  ntp author around how to resolve this issue went to put a
>> "compressed" ipv6  address in this refid field. This in fact changes the
>> current protocol.
>>
> recall) should be there too.

not sure we need to go deep in this document. I agree that it would be nice 
to put a reference to a draft on what is chosen to resolve the issue.

> Is there other than the expired I-D?

none that I'm aware.

> Has

- process was done within the ntp dev team and the small group of 
interested people. there is no ntp wg I know of.

I let the ntp author decide how to do this. I think he had in mind a 
important rev of the ntp documents. IPv6 refid would be a very small part 
of it.

Marc.

---

From: Jean-François Boudreault <[email-masked]>
Date: Wed, 18 Sep 2002 16:30:20 -0400

>the change in the protocol been ratified or in the process of being done

The change has been implemented by ntp dev team and should be ratified in the 
protocol. From a conversation with Dave Mills :

"John Hay implemented the latest, which amounts to the first 32 bits of
an MD5 hash of the IPv6 address."

And you can see in NTP cvs ChangeLog that it as been implemented on 2002-07-29 
:

http://ntp.bkbits.net:8080/ntp-dev/[email-masked]?nav=index.html|ChangeSet@-9M

-- 

-------------------------------
Jean-Francois Boudreault
http://www.viagenie.qc.ca
tel: +1-418-656-9254x228
-------------------------------

-------------------------------
Free IPv6 Connectivity
http://www.freenet6.net
-------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Sep 2002 23:32:17 +0300 (EEST)

Implemented != ratified in the protocol (specification).

There are probably code bases which have nothing to do with Dave Mills'.

---

From: Jean-François Boudreault <[email-masked]>
Date: Wed, 18 Sep 2002 17:03:26 -0400

That's why I said 'should', it isn't ratified yet, last time I talked with 
Dave Mills about ntp it there wasn't any plan. He told me it will take a 
while to do so. From there, we should add this ntp refid case to ipv4survey 
draft as IPv4 protocol dependance. 

>> The change has been implemented by ntp dev team and should be ratified in
>> the protocol. From a conversation with Dave Mills :
>>

--

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 18 Sep 2002 17:03:22 -0400

> There are probably code bases which have nothing to do with Dave Mills'.

you are right. You are suggesting which process?

Marc.

>> > Some reference to that change (to use a hash of a part of the address,
>> > I recall) should be there too.  Is there other than the expired I-D?
>> > Has the change in the protocol been ratified or in the process of
>> > being done so?
>>
>> The change has been implemented by ntp dev team and should be ratified
>> in the  protocol. From a conversation with Dave Mills :
>>
>> And you can see in NTP cvs ChangeLog that it as been implemented on
>> 2002-07-29  :
>>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Sep 2002 04:10:47 +0300 (EEST)

> you are right. You are suggesting which process?

Re-publish the old refid internet-draft or or create a new one; one 
indended to Update the NTP RFC.

Perhaps D. Mills as the NTP author and/or apps Area Director could have 
some ideas how to proceed.

I think you agree that we need to keep this issue up and open until we're 
a bit farther in the NTP for v6 extension specification process.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 19 Sep 2002 10:14:55 +0900

>> <[email-masked]> wrote/a 馗rit:
>> 

	this is a slide i will be using tomorrow.  hope it is useful.

itojun

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%page

32bit IDs

	A lot of protocols use 32bit IDs
	32bit IDs = management headaches, scalability limitation

	What is the domain of uniqueness?
		OSPF - within an AS
		BGP - worldwide uniqueness needed

	How wide does ID need to be?
		128bit - global IPv6 address can be used
		64bit - EUI64 maybe? (not guaranteed to be unique)
		64bit - 32bit AS number + 32bit serial (management headache)
		32bit - insufficient (32bit AS numbers)

---

From: Mathew Richardson <[email-masked]>
Date: Thu, 19 Sep 2002 11:37:21 -0400

> Jun-ichiro itojun Hagino <[email-masked]> [Thu, Sep 19, 2002 at 10:14:55AM +0900]:

<snip>

<snip>

I just thought it was worth mentioning that BGP doesn't require
a worldwide, unique ID.  Indeed, it is my understanding that
even in actual operational deployment, rfc1918 addresses are
often used for BGP IDs.

mrr

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 20 Sep 2002 00:49:58 +0900

>even in actual operational deployment, rfc1918 addresses are

	does the above still hold for EBGP routers?

itojun

---

From: Akira Kato <[email-masked]>
Date: Fri, 20 Sep 2002 01:15:32 +0900 (JST)

>	does the above still hold for EBGP routers?

Yes. It is an ID rather than an address. You can not establish an
(E|I)BGP session between a pair of routers with the same ID. If you
use BGP route reflectors, the ID should be unique in the AS, as well.
If you use BGP route servers, the ID should be unique in the IX, as
well.

In a private peering, randomly choosen IDs from RFC1918 space rarely
cause a collision. It is better to have deterministic ways to define
the IDs in bigger IXes, however.

-- Akira Kato, WIDE Project

---

From: Mathew Richardson <[email-masked]>
Date: Thu, 19 Sep 2002 12:31:30 -0400

> Akira Kato <[email-masked]> [Fri, Sep 20, 2002 at 01:15:32AM +0900]:
>

<snip>

Agreed with all of the above.  I'd say that operationally, even without
route-reflectors, IDs should be unique within the AS.  (IBGP peering
sessions often take place over addresses that correspond to the BGP ID,
for example.)

<snip>

Also agreed.

As a final point, the current BGP specification does require that
the BGP Identifier be set to an IP[v4] address assigned to the
BGP speaker; however, there are deployed implementations that
don't require this.

mrr

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 19 Sep 2002 12:33:55 -0400

> a bit farther in the NTP for v6 extension specification process.

This is more a process item that I leave to the wg chairs to what to do. We 
are open to do whatever is needed to help. We do have good links with the 
ntp team.

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 19 Sep 2002 12:37:15 -0400

-- jeudi, septembre 19, 2002 10:14:55 +0900 Jun-ichiro itojun Hagino 
<[email-masked]> wrote/a écrit:

>>> <[email-masked]> wrote/a ?$BqD?(Brit:
>>>
>

very good start.
one note about eui-64: for any "server-permanent-like" service, generic bcp 
is to not use the eui-64 as the published address so that in the event of 
hardware change, then the published non-eui64 address is still working.

this means that there is a low chance that eui-64 would be a universal 
solution to identifiers. (not that it could not be used, but it has some 
limitations)

Marc.