[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]
Erik,
I just finally got time to read this draft and your discussion about it.
I have some comments relating to the source locator rewriting support,
particularly as it relates to minimizing the need for non-multihomed (or
PI-multihomed) hosts to keep shim context.
The draft says:
The support for this rewriting consists of:
o Introducing a new Sent Locator Pair option, which the receiver or
a packet can use to see how the routers rewrote the locators in a
packet sent towards it. The receiver also "echos" this
information to its peer using the next option.
o Introducing a new Received Locator Pair option, which is a echo of
the content of a received Sent Locator Pair option.
Which I think is reasonable and a beneficial extension... But it also
says:
o The hosts SHOULD include a shim6 extension header for ULP payloads
where the sending shim does not rewrite the locators, in order to
allow the routers to rewrite the locators.
o To maximize the utility of the locator rewriting, we should avoid
the use of deferred context establishment. If the first packet
sent is an I1 packet, and the above SHOULD is honored, then the
routers are free to rewrite the locators in all the packets that
are exchanged between a pair of shim6 hosts. (If we are also
doing complete identifier/locator split, then there is no deferred
context establishment, thus this doesn't add any additional
costs.)
I disagree with this. If a rewriting-capable host, which may or may not
have a rewriting router on the path, started up communication observing
these SHOULDs, then the host it's talking to, which may be a very busy
non-multihomed (or PI-multihomed) server, would have to keep full shim6
context and would be unable to discard it during communication due to the
presence of shim6 extension headers on every packet. This would be true
even if no source-rewriting routers were deployed, and no one gained any
benefit from the capability.
IMO a better approach would be to continue using deferred context
establishment (except in the identifier/locator split case, of course),
and initially only put the Sent Locator Pair option packets that already
have shim6 headers (shim6 control packets and any packets sent with
non-ULID locators). Then, *if* source locator rewriting is done by a
router on *those* packets, you can start putting shim6 extension headers
on all ULP payload packets.
My reasoning for wanting to make the changes above is that IMO there will
be a lot more users who want to minimize shim6 state on their servers than
who want to do shim6 rewriting in their routers, at least initially. If
we start requiring all packets between shim6-capable hosts to have shim6
extension headers, that requires that all shim6-capable hosts keep full
shim6 state for all communications with other shim6-capable hosts, which
in turn means that operators of large servers will turn off shim6
entirely, and it will be of very limited utility due to very limited
deployment.
-Scott
On 03/01/06 at 11:45am -0800, Erik Nordmark <erik.nordmark@sun.com> wrote:
>
>
> -------- Original Message --------
> Subject: I-D ACTION:draft-nordmark-shim6-esd-00.txt
> Date: Tue, 28 Feb 2006 15:50:02 -0500
> From: Internet-Drafts@ietf.org
> Reply-To: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : Extended Shim6 Design for ID/loc split and
> Traffic Engineering
> Author(s) : E. Nordmark
> Filename : draft-nordmark-shim6-esd-00.txt
> Pages : 25
> Date : 2006-2-28
>
> The Shim6 protocol provides for locator agility while satisfying the
> 'first, do no harm' security requirements. This document outlines
> some extensions to Shim6 that in addition provides complete
> separation between identifiers and locators, and allows routers to
> rewrite the locators in the shim6 packets as a way to provide traffic
> engineering information to the hosts.
>
> The document also outlines a simple extension to allow shim6, with a
> CGA upper-layer ID, to operate using IPv4 addresses as locators.
>
> The purpose of this outline is to stimulate discussions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-nordmark-shim6-esd-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-nordmark-shim6-esd-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>