Subject: Re: Revised IPng Working Group Charter

From: "Narsimharao Nagampalli" <[email-masked]>
Date: Thu, 29 Jun 2000 21:53:10 -0600

Flow label is also important for other applications such as server load balancing solutions. Also this could be useful for parallelizing protocol stack workload in a connection level parallelism mechanism.

-Narsi
>>> Brian E Carpenter <[email-masked]> 06/30/00 02:05AM >>>
Alex, I don't think the issue is separable from other QOS issues. That
means that DIFFSERV, INTSERV and ISSLL are all concerned at some level.
So I think it needs to be raised first in the TSV Area meeting. 
I agree that once the topic has been clarified, a work item should
be identified and then we can see which WG should handle it - it can't
be left floating.

(I'm much less clear about routing, I have to say. I suspect that flow-label
based routing would prove to be a pure rathole.)

  Brian

Alex Conta wrote:
> 
> While I agree  with the chairs and the WG that the flow ID work must be completed,
> and I agree with you that the expertise in other IETF areas can be very useful to
> get the flow label work going, I am concerned that the work
> has less of a chance to be completed without a specific WG to do it.
> 
> The "TraffiC Class" field is an example where things worked well: the output from
> the Diff-Serv WG affects directly
> the field.
> 
> Did you have in mind something similar when you made the suggestion?
> 
> Alex
> 
> Brian E Carpenter wrote:
> 
> > I can't hekp wondering whether the flow label issue should be sent off
> > to the Transport area for consideration.
> >
> >   Brian
> >
> > Bob Hinden wrote:
> > >
> > > Folks,
> > >
> > > Attached is a draft of a revised charter for the working group.  Updating
> > > the charter was agreed to at the Grenoble and Minneapolis working group
> > > meetings, but it took the chairs and AD's a while to draft a new one.
> > >
> > > The charter includes changing the name of the working group to the "IP
> > > Version 6 Working Group", but will keep the acronym of "ipngwg".  This will
> > > avoid having to rename all current internet drafts.
> > >
> > > Please send comments on the new charter to the mailing list.  There will be
> > > a short session in Pittsburgh to discuss it as well.
> > >
> > > Bob Hinden / Steve Deering
> > >
> > > -----------------------------------------------------------------------------
> > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft
> > > -----------------------------------------------------------------------------
> > >
> > > IP Version 6 Working Group (ipngwg)  *** note: change of name but not acronym
> > >
> > > Chair(s):
> > >
> > >     Bob Hinden <[email-masked]>
> > >     Steve Deering <[email-masked]>
> > >
> > > Document Editor
> > >
> > >     Bob Hinden ([email-masked])
> > >
> > > Internet Area Director(s):
> > >
> > >     Thomas Narten <[email-masked]>
> > >     Erik Nordmark <[email-masked]>
> > >
> > > Internet Area Advisor:
> > >
> > >     Thomas Narten <[email-masked]>
> > >
> > > Mailing Lists:
> > >
> > >     General Discussion:[email-masked] 
> > >     To Subscribe: [email-masked] 
> > >     In Body: in body: subscribe ipng
> > >     Archive: ftp://playground.sun.com/pub/ipng/mail-archive 
> > >
> > > Description of Working Group:
> > >
> > >     IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng)
> > >     is intended to support the continued growth of the Internet, both in
> > >     size and capabilities, by offering a greatly increased IP address space
> > >     and other enhancements over IPv4.  The working group was originally
> > >     chartered to implement the recommendations of the IPng Area Directors
> > >     as outlined at the July 1994 IETF meeting and in "The Recommendation
> > >     for the IP Next Generation Protocol," RFC1752, January 1995.  Most of
> > >     the tasks in that original charter have been completed, and the core
> > >     IPv6 protocol specifications are now on the IETF standards track.
> > >     The working group's ongoing responsibilities are as follows:
> > >
> > >      - Complete work from the original charter and follow-on work, as
> > >        outlined below.
> > >
> > >      - Keep all IPv6 working group documents moving along publication /
> > >        standardization track.
> > >
> > >      - Serve as a review board and body of competence and coordination for
> > >        IPv6 architectural issues that span multiple IETF working groups.
> > >
> > >      - Provide a home for IPv6-related work that doesn't fit in an existing
> > >        IETF working group and doesn't merit a working group of its own.
> > >
> > >      - Provide technical input to ICANN, Internet Address Registries, and
> > >        IANA with regard to IPv6 address allocation policies and procedures.
> > >
> > >      - Provide technical input and review to IANA with regard to IPv6
> > >        protocol and parameter assignments.
> > >
> > >     The list of the working group's current work items is as follows:
> > >
> > >      - Revise ICMPv6 spec (scope-exceeded err, no error to redirect,
> > >        editorial)
> > >      - Revise Generic Tunneling spec (add bidirectional tunnels)
> > >      - Update Basic and Advanced API specs
> > >      - Complete Router Renumbering spec
> > >      - Complete Scoped Address Architecture spec and any necessary revisions
> > >        to other working group drafts required to properly implement support
> > >        for IPv6 address scoping
> > >      - Complete work on recommended address-selection algorithms
> > >      - Work on new solutions to site-multihoming problems, possibly including
> > >        both host-based and router-based solutions.
> > >      - Complete work on local IPv6 networking as part of IPv6 plug-and-play
> > >      - Complete work on privacy extensions to stateless address configuration
> > >      - Document IPv6 renumbering model
> > >      - Complete the GSE Analysis document
> > >      - Complete the Inverse Neighbor Discovery spec
> > >      - Complete the IPv6 Node Information Queries spec
> > >      - Complete MIB specs as required by any working group protocol specs
> > >
> > >     New work items not listed above require the approval of the working
> > >     group and Internet Area directors before they will be taken on by the
> > >     working group.
> > >
> > >     The working group would welcome contributions on the following topics
> > >     (this is not an exhaustive list):
> > >
> > >      - Flow label standardization
> > >      - Solutions to other multihoming issues, beyond those specific to
> > >        site-multihoming
> > >      - Integration of autoconfiguration, mobility, DNS, service discovery
> > >        and other technologies to enhance IPv6 plug-and-play
> > >      - IPv6 dial-up issues relating to address assignment, use of Neighbor
> > >        Discovery, etc. (not including AAA work)
> > >      - Specifications for IPv6 over additional media
> > >      - Extending MLD to include functionality of IGMPv3
> > >      - Host use of anycast; TCP use of anycast
> > >      - Support for multi-link subnets (single subnet spans multiple links)
> > >      - Scope-name discovery
> > >      - IPv6 protocol extensions to accommodate mobile wireless networks.
> > >
> > > Goals and Milestones:
> > >
> > >   Aug 2000    Complete MLD MIB and submit for Proposed Standard
> > >
> > >   Aug 2000    Complete privacy extensions specification and submit for
> > >               Proposed Standard
> > >
> > >   Aug 2000    Completed revision of GSE Analysis document and resubmit
> > >               for Informational
> > >
> > >   Aug 2000    Complete the Inverse Neighbor Discovery specification
> > >               and submit for Proposed Standard
> > >
> > >   Aug 2000    Complete IPv6 Multihoming with Route Aggregation and submit
> > >               for Informational.
> > >
> > >   Oct 2000    Update ICMP document and resubmit for Draft Standard
> > >
> > >   Oct 2000    Update Generic Tunneling specification and resubmit for
> > >               Proposed Standard
> > >
> > >   Oct 2000    Complete updates to Basic and Advanced API specifications
> > >               and submit for Informational
> > >
> > >   Dec 2000    Complete Scoped Address Architecture and submit for Proposed
> > >               Standard
> > >
> > >   Dec 2000    Compete Address Selection specification and submit for Proposed
> > >               Standard
> > >
> > >   Dec 2000    Complete Local IPv6 Networking Specification and submit for
> > >               Proposed Standard
> > >
> > >   Dec 2000    Complete the IPv6 Node Information Queries specification
> > >               and submit for Proposed Standard
> > >
> > >   Mar 2001    Complete IPv6 renumbering model document and submit for
> > >               Informational
> > >
> > > -----------------------------------------------------------------------------
> > > Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft - Draft
> > > -----------------------------------------------------------------------------
> > >
> > > --------------------------------------------------------------------
> > > 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] 
> > > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > 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] 
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> 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] 
> --------------------------------------------------------------------
--------------------------------------------------------------------
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] 
--------------------------------------------------------------------
--------------------------------------------------------------------
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: Scott Bradner <[email-masked]>
Date: Fri, 30 Jun 2000 11:25:36 -0400 (EDT)

if the only thing the redirector does is forward out a special port to
a particular server (or tunnel to the server) and all the servers
are running as if they are using the same IP address this should work - but
many redirectors operate as NAT boxes and fiddle with the IP addresses
in the IP header which breaks IPSec 

scott

---

From: Scott Bradner <[email-masked]>
Date: Fri, 30 Jun 2000 20:32:40 -0400 (EDT)

> So can it be given a few minutes in the TSV WG in Pittsburgh, at least to
> see if there is any interest/volunteers?

if someone wants to take a few min to talk about teh IPv6 flow label
during the tsvwg session in Pittsburgh (assuming we hold one which
depends on having things to talk about) please let Allison & me know

Scott

---

From: [email-masked]
Date: Fri, 30 Jun 00 21:01:19 EDT

> during the tsvwg session in Pittsburgh

I think this would be a good idea.

> (assuming we hold one which depends on having things to talk about)

Actually, we are definitely having one. We have one agenda item, 
and would have room in the same hour for a short flow label
discussion.

Allison