Subject: Re: I-D ACTION:draft-bagnulo-pshim6-00.txt
From: Brian E Carpenter <[email-masked]>
To: shim6-wg <[email-masked]>
Date: Wed, 28 Feb 2007 15:14:34 +0100

I'm glad to see this written up, and I like
many aspects of it. I do have a couple of remarks

1. Exactly as with draft-farinacci-lisp, there is
a clear question whether it's wise to depend so
heavily on DNS for locator mapping. Or should we
invent a separate map distribution mechanism?

2. I think we could probably use unregistered
ULAs and some fairly simple clash-detection mechanism.
Otherwise, we will be creating registration expense
for no very good reason.

     Brian

Delivery-date: Wed, 28 Feb 2007 11:47:25 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: shim6 proxies
Date: Wed, 28 Feb 2007 12:46:36 +0100

Hi,

i have included in this draft some level of detail on how to do proxies 
in shim6, in order to support unmodified hosts, allow some middle boxes 
to perform egress path selection and provide PI identifiers, so that we 
can have an idea of how this would look like in the shim approach

Comments are welcome

Regards, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
> Para: [email-masked]
> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Proxy Shim6 (P-Shim6)
> 	Author(s)	: M. Bagnulo
> 	Filename	: draft-bagnulo-pshim6-00.txt
> 	Pages		: 22
> 	Date		: 2007-2-27
> 	
>    This draft discusses extensions to the shim6 architecture to support
>    shim6 proxies that would allow the provision of the following
>    capabilities:
>    o  Provide Upper Layer Identifier portability.
>    o  Provide Traffic Engineering policy enforcement.
>    o  Off-load of the shim6 context management from the actual peers of
>       the communication.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-bagnulo-pshim6-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:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bagnulo-pshim6-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.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

Delivery-date: Sun, 04 Feb 2007 20:07:51 +0000
Date: Sun, 04 Feb 2007 15:05:13 -0500
From: Jari Arkko <[email-masked]>
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07

Sébastien,

Thank you for the questions -- its always good to hear what
implementors have found problematic in a spec.
>
> section 3.1 : available addresses
> ----------------------------------------------------
> -- 
> Where IPv6 link-local addresses are used, their use needs to be
>      unambiguous as follows.  At most one link-local address may be
>      used per node within the same connection between two peers.
> -- 
>
> Why ? What is the problem in dealing with multiple link-local addresses ?
> In fact, I think the problem is not in dealing with multiple
> link-local addresses, but rather in making sure we use a link-local
> address over the right link.
>

Right.

> * Using the peer's link-local address (announced during shim6
> intialization in the peer locator set) : The problem is that we have
> no way to know if the peer is in the same subnetwork as us. Moreover,
> if we have multiple interfaces, which is the one corresponding to the
> given link-local address ? Because of this, I think it is not correct
> to send the link-local addresses as part of the locator list during
> shim6 initialization without a proper mechanism, but I also guess it
> is not worth designing such a mechanism, given the limited interest in
> doing that.
> * Using the local link-local address as source for exploration : If we
> use our link-local address as source, we know over which link to use
> it, but this is not really useful if we don't know if our peer is
> inside our subnetwork.
>
> * In summary, it appears to me that link-local addresses are not
> really suitable for use with shim6/reap. Am I missing something ?
>

Not really. The draft does not explain the reasons why it
was left out, but its more or less according to what you
describe above. Its something that we could make work,
perhaps, but I also am not sure the effort is worth it.
>
> State machine (table 4)
> --------------------------------------
>
> -- 
> Upon a timeout on the Send timer, the node enters the Exploring
>   state, sends a Probe, and stops the Keepalive timer if it was
>   running.
> -- 
> Why to stop the Keepalive timer ? Isn't it always stopped when the
> send timer is running ? (so necessarily also if it does a timeout).

Right. Thanks for catching this. There also are two extra STOP <timer>s
in the state machine, stopping a timer that just timed out.

>
>
> Incoming probe Inbound OK
> ----------------------------------------------
>
> As specified in the draft, the reception of a probe Inbound OK
> triggers a come back to the operational state. But a come back to the
> operational state implies that a pair of working locators are given to
> the shim, for use as current locator pair. AFAIK, this locator pair
> must be chosen in the list of probes received : each received probe
> report contains a working locator pair, which may be chosen as the new
> current locator pair. Now, the problem is that it is possible to
> receive a probe Inbound OK without any probe reception report inside. 

reading on...

> For example, if the peer receives an incoming packet while in state
> exploring, it will send an Inbound OK probe without any source
> reception report. In this case the receiver of that probe is only able
> to know that *there is* a working locator pair, but it cannot know
> which is that locator pair. In fact I guess we have two solutions to
> solve this :
> - Let the draft as is : When we receive a probe Inbound OK without any
> received probe report (Precvd=0), we conclude that a payload packet or
> a keepalive has been received by the peer, which means that we can
> come back to the operational state without changing the current
> locators. (Because payload packets and keepalives are sent with
> current locators).
> - Find some way to report the reception of data packets/keepalives :
> In the case of probes having been received, this would allow to tell
> the peer that also the current locator pair is working.

Very interesting case, indeed!

I agree that this is a problem. I would prefer your first solution
(or at least not changing the locator pair used for one direction,
perhaps there was some other reason to change the other).

Jari