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

Re: shim6 proxies

Hi Shinta,

Thanks for reading and commenting the document...

see below...

El 01/03/2007, a las 4:57, Shinta Sugimoto escribió:


Hi Marcelo,

I read your draft and found it insightful. I had a couple of
questions as below:

- I am not sure if I understand the definition of CMULA and its
  expected role in P-shim6, so please help me clarify. According to
  draft-ietf-ipv6-ula-contral-01.txt, CMULAs are not expected to be
  routable globally.  However, reading the P-shim6 draft, I assume
  that CMULA need to be globally routable addresses.


CMULAs in the P-shim6 draft are not routed gloablly
CMULAs are only used a ULIDs and are never used a locators for shim6 contexts current shim6 uses one of the PA addresses as the ULIDs, so the ulids depend on the provider.
The goal in P-shim is to only configure provider independent addresses (which are not globally routable) in the nodes within the multihomed site, so that renumbering is trivial The problem is that since they are not routable, you need to establish the shim6 context before exchanging packets using alternative locators. (this is basically what was proposed by Erik in http://tools.ietf.org/wg/shim6/draft-nordmark-shim6-esd-00.txt) 

makes sense?


  And if there is any problem with assigning more than one CMULA
  blocks to a multihomed site?


no but this is not needed AFAICT
I mean, CMULAs are the ULIDs, and are provider independent, so i am not sure why would you need more than one block... 


- In Section 5, it is mentioned that P-shim6 box virtually assigns
  PA address for each host and uses it as locator for each
  multiplexing/demultiplexing for the proxy-shimmed flow.
  But wouldn't it be possible for the P-shim6 box to use a PA
  address as a common locator for multiple clients?


yes, this would be possible
This does present some problems AFAICT especially when you want to fall back from the primary P-shim to the secondary P-shim, since the packets are addressed to the p-shim itself In addition, if you want to provide communication with legacy nodes outside the multihomed site that are not served by any P.shim, you still need to assign PA addresses to each node in the multihomed site 


 I would
  think that proxy-shimmed payload traffic can be normally
  demultiplexed to CMULA on the receiver.  Sharing common locator
  may help to reduce costs of REAP failure detection.


yes this could be an optimization, i agree
I am not sure if no changes are needed for this, in the reap logic, but i think this could be done
in order to do this, you would need that the backup p-shim would take over the address of the primary p-shim when this one fails. I am not sure what could be the complexity added by this. 


  I missing something?
i don't think so, this is another possibility and i worth to explore its benefits deeper 


- The draft says that P-shim6 box should be the DNS server for
  the hosts, providing DNS relay in a specific manner; inducing
  the host to access to its peer with ULID.  But I am wondering
  if such role can be played by other DNS server (!= P-shim box)
  as well.  Is there any reason why P-shim6 box should be involved
  in address resolution requested by host?
Yes, because the DNS reply returns the ULID and the locators. the P-shim stores the locators and includes the ULID in the DNS reply to the host. when the host sends the first packet to the peer, it includes the ULID in the dest address field. when the packet reaches the P-Shim, the P-shim box has the locator information associated to this ULID because it was returned in the original DNS reply 
makes sense?

regards, marcelo



Regards,
Shinta

On Wed, 28 Feb 2007 12:46:36 +0100
marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:



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: Internet-Drafts@ietf.org
Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
Para: i-d-announce@ietf.org
Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
Responder a: internet-drafts@ietf.org

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
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-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:
	mailserv@ietf.org.
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: <2007-2-27120849.I-D@ietf.org>

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce