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 PROTECTED]> 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 PROTECTED]>
> > > Steve Deering <[EMAIL PROTECTED]>
> > >
> > > Document Editor
> > >
> > > Bob Hinden ([EMAIL PROTECTED])
> > >
> > > Internet Area Director(s):
> > >
> > > Thomas Narten <[EMAIL PROTECTED]>
> > > Erik Nordmark <[EMAIL PROTECTED]>
> > >
> > > Internet Area Advisor:
> > >
> > > Thomas Narten <[EMAIL PROTECTED]>
> > >
> > > Mailing Lists:
> > >
> > > General Discussion:[EMAIL PROTECTED]
> > > To Subscribe: [EMAIL PROTECTED]
> > > 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 PROTECTED]
> > > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > 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 PROTECTED]
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> 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 PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
