Subject: IPng Agenda for Minneapolis IETF

From: Bob Hinden <[email-masked]>
Date: Tue, 13 Mar 2001 20:29:38 -0800

Attached is the draft agenda for IPng w.g. sessions at the Minneapolis 
IETF.  We have tried to allow enough time for each talk to permit a 
reasonable amount of discussion.  We are also including a track at the end 
of the second session to allow for discussing the use of the IPv6 flow 
label.  More information on this will be sent out soon.

Please send us comments, additions, and deletions.

Thanks,
Bob Hinden <[email-masked]>
Steve Deering <[email-masked]>

-------------------------------------------------------------------------

MONDAY, March 19, 2001  0900-1130 (Salon D)
-------------------------------------------

Introduction / S. Deering (5 min)
Review Agenda / S. Deering (5 min)
Document Status / R. Hinden (10 min)

Source/Destination Address Selection / Rich Draves (30 min)
    <draft-ietf-ipngwg-default-addr-select-03.txt>

Default Router Preferences & More Specific Routes in RAs / Rich Draves (20 min)
     <draft-draves-ipngwg-router-selection-01.txt>

Generic Packet Tunneling in IPv6 - Bi-directional Tunneling / Alex Conta 
(15 min)
     <draft-conta-extensions-ipv6-tunnel-01.txt>

An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min)
    <draft-itojun-ipv6-anycast-analysis-02.txt>

Host-based Anycast using MLD / Brian Haberman (30 min)
    <draft-haberman-ipngwg-host-anycast-00.txt>

Site prefixes in Neighbor Discovery / Erik Nordmark (30 min)
    <draft-ietf-ipngwg-site-prefixes-05.txt>

THURSDAY, March 22, 2001 1530-1730 (Salon D)
--------------------------------------------

IPv6 Scoped Address Architecture / Steve Deering (10 min)
    <draft-ietf-ipngwg-scoping-arch-02.txt>

IPv6 Near-Unique Site-Local Addresses / Paul Francis (20 min)
    <draft-francis-ipngwg-unique-site-local-00.txt>

DNS Server Discovery Mechanisms for IPv6 Update / Dave Thaler (15 min)
    <draft-ietf-ipngwg-dns-discovery-00.txt>

Multicast Listener Discovery Version 2 (MLDv2) for IPv6 / Luis Costa (10 min)
    <draft-vida-mld-v2-00.txt>

IPv6 Flow Label Track (60 min)

    Flow Transparent Mobility and QoS Support for IPv6-based Wireless Real-time
    Services / Winston Seah (10 min)
       <draft-shen-ipv6-flow-trans-00.txt>

    [Other talks to be announced]

-----------------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Tue, 13 Mar 2001 23:24:34 -0800

As Bob mentioned, we have set aside a chunk of time in the Minneapolis
agenda to discuss the various proposals for what to do with the IPv6
Flow Label field.  This was a hot topic here on the list just before
the San Diego IETF, and then we ended up with an agenda that was too
full to allow in-depth face-to-face discussion, so we said we would
defer it to the proposed interim meeting, which never happened.
Therefore, we have made time next week for this topic.

At the moment, we have one scheduled presentation on Flow Label issues,
by Winston Seah (draft-shen-ipv6-flow-trans-00.txt), and we would like
to offer the opportunity for others who were arguing for alternative
semantics for the Flow Label field to summarize their proposals.  If
I recall correctly, the debate came to down to basically three
different choices for Flow Label semantics:

    (1) a non-mutable value that, when concatenated with the source
	address, can be used by routers to identify flows.  (This was
	the original design, described in pre-RFC2460 versions of
	the IPv6 spec.)

    (2) a mutable value that can be or will be modified hop-by-hop,
	like an ATM virtual circuit identifier or an MPLS label.

    (3) a hybrid of (1) and (2) in which, say, one bit of the Flow
	Label field indicates whether or not the rest of the field
	is mutable.

It would be best if we had one presenter for each of those choices
(assuming my list of the different choices is right), with 10 minutes
provided for each speaker to make their case.  I.e., if, for example,
five people all volunteer to make the case for choice (2), we will
ask them to choose one presenter among themselves to summarize all
the arguments.  The goal is to quickly lay out all the issues, and
then allow some time for interactive discussion and trying to see if
any sort of consensus might emerge.  (Of course, any results will be
written up in the minutes and subject to further discussion/ratification
here on the list and in Last Calls, etc.)

So, if anyone would like to make a summary presentation of a Flow Label
proposal, please send a message to Bob and me (you may also cc it to
the list if you wish, or not), saying in a sentence or two what your
specific proposal is.  If there are multiple people proposing the same
thing, we'll ask that set of people to coordinate on a single presentation.

OK?

Steve

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Mar 2001 12:09:53 +0100 (CET)

> 	Label field indicates whether or not the rest of the field

I understand that the above 3 are the currently understood alternatives
for what the flow label semantics could be.

I think that I could construct arguments for either one of them
being the best; it all depends on what problem I think the 20 bits could be
used to solve. So while it might be useful to get arguments for and against the
various semantics on the table, there is a risk that this isn't productive is
folks have very different views of what problem they can solve using the flow
label field.

Thus before the WG can actually make any decisions about flow label
semantics I think we need to have folks write up the different
problem statements for which they see the flow label as a potential solution.
Then the WG can decide which problem(s) are the most important to solve
and whether or not using the flow label is the best solution. That would
then hopefully lead to nailing down the semantics of the flow label.

So having the discussion you propose is fine, but please keep the problem
statements in mind.

  Erik

---

From: Steve Deering <[email-masked]>
Date: Wed, 14 Mar 2001 08:16:28 -0800

>So having the discussion you propose is fine, but please keep the problem

Excellent point, Erik.  Clearly, we don't have time for much writing up
before the meeting, but those of you who wish to make presentations
should include a description of what problems you are trying to solve,
why those are essential problems to solve, and why using the IPv6 Flow
Label is the best or only way to solve them.  It would be good if our
discussion helps to focus the problem space and the set of potential
solutions, so there will be fewer drafts that need to be written and
argued about afterwards.  (Well, one can hope... :-)

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 14 Mar 2001 08:31:10 -0800

At 8:16 AM -0800 3/14/01, I wrote:
>...those of you who wish to make presentations should include a
>description of what problems you are trying to solve, why those are
>essential problems to solve, and why using the IPv6 Flow Label is
>the best or only way to solve them.

Just to clarify: that information should be included in the presentation;
I'm not asking you to include all that in the email you send to Bob and
me requesting a presentation slot.

Steve

---

From: Alex Conta <[email-masked]>
Date: Fri, 16 Mar 2001 17:00:56 -0500

Very good, in fact, essential point.

Reserving the time on the agenda is very welcome.  Given the somewhat
short notice - I was on travel and could not see the note until Friday
afternoon -  I am hoping that all ideas or points 
will be formulated and expressed, but in case not, the topic should be
kept open for discussion on the mailing list, for a while, before taking
decisions.

Regards,
Alex