[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New version of charter text



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-----