Subject: Pseudo "last call" for draft-ietf-ipngwg-ipv6-2260-02.txt

From: Thomas Narten <[email-masked]>
Date: Fri, 27 Jul 2001 16:55:19 -0400

The document "IPv6 multihoming support at site exit routers"
<draft-ietf-ipngwg-ipv6-2260-02.txt> came out of the IPng WG, which
has requested that it be published as an informational RFC. Given that
the subject of the draft overlaps with the main focus of this group,
we'd be interested in getting WG feedback on the contents of the
document. Namely:

 - is the document reasonable to publish as an informational RFC as
   is, or are some specific changes appropriate?

 - How feasible do the techniques described in the document appear to
   be from the perspective of an operator?

 - What are the main (if any) limitations to using the described
   techniques from an operational perspective? Are these limitations,
   if any, adequately described in the document?

Explicit feedback (including "looks fine to me") from all those who
read it would be helpful.

Sean & Thomas
Multi6 WG Chairs

---

From: [email-masked]
Date: Sun, 29 Jul 2001 20:53:14 +0900

>Personally, I find the approach workable in theory but rather awkward in
>practise; I don't see one's upstream operator(s) jumping with joy if
>they'd have to set up and operate a rather extensive "link backup
>service", co-operating with their competitors.  In an academic,
>no-money-exchanged world this probably works better.

	actually, you may use it with two POPs of a single ISP too.
	if they do not aggregate per-POP you can use a single prefix and
	advertise routes normally.
	if the upstream ISP aggregates per-POP, you may get two /48 from
	them and operate these two prefixes (the scenario is closer to
	two different ISP case).

itojun

---

From: Pekka Savola <[email-masked]>
Date: Sun, 29 Jul 2001 14:38:19 +0300 (EEST)

These are in reality rather big operational and management issues, and
I believe should be stated more clearly.

So, I'm a little sceptic of the wide-spread value of this, but the idea is
interesting and worth an informational RFC.

I think _explicit_ Goals should be stated more clearly (as non-goals have
been); as far as I can see, this method protects against ISP link failure
and your edge router failure. "Why should I use this mechanism?" if I may.

-- 
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: "Craig A. Huegen" <[email-masked]>
Date: Mon, 30 Jul 2001 08:57:33 -0700 (PDT)

> no-money-exchanged world this probably works better.

From an enterprise end-user point of view, this approach adds more
confusion to a solution that already has major concerns.  The number 1
concern that we have to deal with in this multihoming scheme is the path
selection by the originating TCP stack through its selection of source and
destination addresses.

The tunnel adds a kludge under the guise of resiliency.  It will be hell
to troubleshoot in case of a failure of the primary link, and has the
potential to introduce a suboptimal path that would be better addressed
through utilizing another provider.

/cah

---
Craig A. Huegen  CCIE #2100                       C i s c o  S y s t e m s
Sr Network Architect, GCTS                              ||        ||
Cisco Systems, Inc., 400 East Tasman Drive              ||        ||
San Jose, CA  95134, (408) 526-8104                    ||||      ||||
email: [email-masked]                           ..:||||||:..:||||||:..