Subject: draft-ietf-multi6-multihoming-requirements-03.txt

From: [email-masked] (Sean Doran)
Date: Wed, 23 Oct 2002 01:19:23 +0000 (GMT)

This draft expires in one week on 30 October 2002.

Have you read it?  Do you think it's ready?  
Do you think it's not ready?  Do you have an
idea you think should be incorporated into
the draft?

Comments, please.

Incidentally, three other important dates are coming in the near future:
the pre-IETF draft cutoffs for initial and final submissions and the
cut-off for scheduling a WG meeting (October 29), should we have wg business
to discuss in Atlanta.

	Sean.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Oct 2002 13:11:59 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Sean" == Sean Doran <[email-masked]> writes:
    Sean> This draft expires in one week on 30 October 2002.

  I guess that the draft has expired once already in June.
My scripts picked up the new copy from June 11th again, but didn't sort it
properly for me, so it looked like it was still expired.

    Sean> Have you read it?  Do you think it's ready?  Do you think it's not

  I have just re-read it from top to bottom, and I think that it is ready.

  I partially agree with Brian Carpenter - perhaps MUST should be removed.
I am do not feel strongly about this.

  There are a number of sections with significant outs - 3.2.3 - impact on
hosts in particular. I am concerned about this topic - I believe that the
degree of impact to end hosts is where we will decide upon a good vs
bad solution. I don't think that the wording of the requirements should
change here, just that this is where the contention will be.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Oct 2002 15:01:40 +0200

As I suggested on the other thread, remove the MUST/SHOULD normative
language - make everything lower case should/should not - and ship it
as Informational.

Use it as guidance for further work.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: "Craig A. Huegen" <[email-masked]>
Date: Wed, 23 Oct 2002 12:51:07 -0500 (Central Daylight Time)

> idea you think should be incorporated into

Two changes I recommend:

Insert between 3.1.4 and 3.1.5 (alternative is placing it into the
"3.1.6 transport-layer survivability" section, although that doesn't
completely address the issue:

---
3.1.x Alternate path visibility

  Multihoming solutions must not constrain alternate path visibility to
  the originating host only.  Multihoming solutions should allow
  alternate path visibility to reside within the network infrastructure,
  such that the multihomed site's operator may easily configure policy to
  prefer a given set of paths.  This may include host and
  network-infrastructure interaction to determine the best path.
---

Discussion:  See previous threads.  The goal is to allow network
infrastructure to have visibility into alternate paths for IP traffic, and
not constrain them to the originating host.

An addition to 3.2.6:

---
A multihoming solution must not require cooperation between the
multi-homed site and other transit providers not providing service to
said multi-homed site.
---

Discussion:  A requirement or possibility for a multihomed site to
establish a business relationship with many, or every, transit provider is
unreasonable.  Multihoming solutions should work and provide reachability
to an end-site provided the guidelines are adhered to, without the need
for a site to establish settlement with a significant number of transit
providers to carry any routing information.

/cah

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 23 Oct 2002 10:51:30 -0700

On Wednesday, Oct 23, 2002, at 06:01 US/Pacific, Brian E Carpenter 

> Use it as guidance for further work.

I like this plan. I seem to think that recommendation-flavoured 
must/shoulds were what was in the document to start with anyway, and 
that the MUST/SHOULDs were added later following comments from this 
list, but I could be mistaken.

Joe

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 23 Oct 2002 23:08:43 -0400

I propose that the chairs schedule a meeting in Atlanta to discuss
the above draft and try to see whether or not it is ready for 
advancement.
Even if not ready for advancement, a meeting to discuss the draft
might highlight which areas lack consensus and thus help focus future
discussions.

I'd ask that the author resubmit the draft if necessary in order to 
ensure
that the I-D not expire before/during IETF Atlanta.

I believe the above to be within charter for this WG.

Ran