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

Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]

Hi Scott,
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.
I guess that what you want is first to discover if there is s router rewriting in the path and if this is so, then enable this capability for the particular shim6 context.
The problem that i see with this is that i don't think it is trivial to detect if a rewriting router is in the path. In particular, i don't think that the context establishment exchenge is enough to detect such presence, especially because it may well happen that during the context estbalihsment exchenge, the source address match with what the router would have rewritten, and even if there is a rewriting router in the path, the source address is unchanged.
I guess it hard to have both aggresive garbage collection and source address rewriting and i guess each site will preffer one capability over the other. So i guess that the best we could do is to provide tools so that each site can benefit from the capability that it preffers the most. 

Regards, marcelo
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.