Re: New version of charter text

[marcelo bagnulo braun <[e-mail]>]

Hi Kurtis,

imho this is very good.
just a few nits, questions below...

El 26/01/2005, a las 13:20, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> 	All,
>
> please find below a new version of the charter text. And my apologies
> for this taking some time.
>
> Some notes,
>
> - - I tried to address Pekka's concerns with TE, and someone in a mail
> proposed an applicability document. I can't find that mail now so I am
> not sure they referred to the same issue, but I would think that
> documenting what uses you get from shim6 under what conditions would
> address Pekka's comment. There is probably more that needs to be
> documented in the same way.
>
> - - I included Marcelo's proposed work item on communication
> establishment.
>
> - - I changed the reference to a state machine to John's proposed text 
> on
> "multihoming triggers" that better referred to what I had originally
> through. I read Brian as still disagreeing (and I think I do to) on
> separating the statemachine from the protocol spec, but we seem to be
> the only two arguing for that :-)
>
> - - I moved the timeline for the protocol document a bit further away 
> as
> per Erik's comment.
>
> I hope that should cover most of what has been discussed.
>
> - - kurtis -
>
> - ----
>
>
>
> Site multiHoming by IPv6 interMediation (shim6)
>
> Description of Working Group:
>
> The shim6 WG is to produce specfifications for a complete IPv6 site
> multihoming solution based on the architecture developed by the IETF
> multi6 WG. The multi6 WG was tasked with investigating solutions to
> the site multihoming problem that will allow the global routing system
> to
> scale. The outcome of the multi6 WG is a specific network layer shim
> architecture for addressing and address handling of sites and nodes.
> This
> includes switching to different locator addresses when connectivity
> changes,
> but without the changes of address being visible to upper layers, which
> see
> a fixed Upper Layer Identifier address (ULID).
>
> The shim6 WG is to complete this work with the required protocol
> developments
> and complete the architecture and security analysis of the required
> protocols.
>
> The background documents to be considered by the WG include:
>
>   RFC 3582
>   draft-ietf-multi6-things-to-think-about-01.txt
>   draft-ietf-multi6-multihoming-threats-03.txt
>
> The input documents that the WG will use as the basis for its design
> are:
>
>   draft-huston-solution-stilltobewritten
>   draft-ietf-multi6-functional-dec-00.txt
>   draft-ietf-multi6-l3shim-00.txt [to be published shortly]
>

FWIW this one is already available FWIK

>   draft-ietf-multi6-failure-detection-00.txt [to be published shortly]
>   draft-ietf-multi6-hba-00.txt
>   draft-ietf-multi6-app-refer-00.txt
>
> The shim6 WG is to submit, as standards track RFCs, specifications with
> enough details to allow full interoperable implementations of the shim
> layer appproach to multihoming as agreed on by the multi6 WG. These
> implementations should have the ability to take advantage of
> multihoming without adding to the growth of the global routing table,
> by using the aggregates already announced by their upstream providers.
>
> Since the solution requires state to be maintained at both ends of a
> communication, the protocol specification docuement needs to contain a
> state machine description.
>
> Some state transitions may result from external events however, such
> as failure detection rather than from protocol events. These should be
> documented in a seperate draft.
>
> Multihoming is today also often used to achieve various other
> features, such as traffic-engineering. The Shim6 WG should document
> the use of the shim6 solution in these cases in an applicability
> document.
>
> More work items and milestones might need to be added at a later date 
> to
> complete all implementation details needed.
>
> In addition to the basic network layer shim solution, the shim6 WG
> is specifically chartered to do work on
>
>       o Solutions for site exit router selection that works when each 
> ISP
>         uses ingress filtering, i.e. when the chosen site exit needs to
> be
>         related to the source address chosen by the host. This solution
>         should work whether or not the peer site supports the shim6
> protocol.
>
>       o Solutions to establish new communications after an outage has
>         occurred that does not requires shim support from the
>         non-multihomed end of the communication. The wg will explore
>         if such solutions are also useful when both ends support the
> shim.
>
>       o Explore how congestion control and other QoS and traffic
> engineering
>         issues may interact with the use of multiple locators at both
> ends.
>
>       o Investigate relationship between Upper Layer Identifiers 
> (ULIDs)
>         and Unique Local Addresses.
>
>       o ICMP error demuxing for locator failure discovery.
>
>       o If necessary, develop and specify formats and structure for
>
>         - Cryptographically protected locators
>
>         - Carrying the flow label across the shim layer
>           defined in the multi6 architecture.
>
> The WG will consider whether the proposed model is exposed to
> any security threats in addition to those documented in
> draft-ietf-multi6-multihoming-threats-03.txt. In any case,
> the specifications must specifically refer to all applicable threats
> and describe how they are handled,  with the requirement being that
> the resulting solution not introduce any threats that make the
> security any less than in today's Internet.
>
> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative
> identifier formats. However, the WG will consider developing methods
> for the shim6 level to handle transport layer signalling to the shim6
> layer as in scope.
>
> [What other topics are explicitly in/out of scope?]

what about a new shim API? I mean a new API that allows the apps to 
communicate with the shim and inform about failures or other stuff, 
would this be within scope?

>
> Milestones
>
> MAY 05    First draft of architectural document
> MAY 05 	  First draft of protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on multihoimg triggers description
> MAY 05 	  First draft on applicability statement document
>
> SEP 05    WG last-call on architectural document
> SEP 05	  WG last-call on applicability statement document
>
> NOV 05 	  WG last-call on protocol document
> NOV 05    WG last-call on cryptographic locators, if required
> NOV 05    Submit completed architectural document to IESG
> NOV 05	  Submit applicability statement document to IESG
>
> JAN 06    WG last-call on multihoming triggers description
> JAN 06    Submit document on cryptographic locators to the IESG, if
>      	  required
> JAN 06	  Submit protocol document to the IESG
>
> MAR 06    Submit draft on multihoming triggers description to the IESG
>

Don't we need to include the additional items that are mentioned above 
as milestones also, such as: ingress filtering solution, mechanism for 
establishing new communications with legacy hosts, TE capabilities 
description?

Regards, marcelo

> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQfeLAaarNKXTPFCVEQK8agCgl5mYm6RZ7wensMPMjXXhY3uQx0AAoOJe
> eNPFzAkch34CwHSYK3TlvNsx
> =4QmB
> -----END PGP SIGNATURE-----
>
>