Re: shim6 proxies

[marcelo bagnulo braun <[e-mail]>]

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 <[e-mail]> 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: [e-mail]
>>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>>> Para: [e-mail]
>>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>>> Responder a: [e-mail]
>>>
>>> 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
>>> [e-mail] 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:
>>> 	[e-mail].
>>> 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: <[e-mail]>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
>