Subject: comments on draft-ietf-shim6-failure-detection-06.txt {2}
From: Deguang Le <[email-masked]>
To: [email-masked]
Date: Sat, 30 Sep 2006 16:47:13 +0200

Hi all,
Two more comments

-Page8
    SHIM6 needs to avoid sending packets concurrently over multiple
    paths, because congestion control in commonly used transport
    protocols is based upon a notion of a single path.  While routing can
    introduce path changes as well and transport protocols have means to
    deal with this, frequent changes will cause problems.  Efficient
    congestion control over multible paths is a considered research at
    the time this specification is written.
This paragraph presents "SHIM6 needs to avoid sending packets
concurrently over multiple path".

However, in RFC 3582 - Goals for IPv6 Site-Multihoming Architectures,
Load sharing is one of the goals of multihoming.
3.1.2.  Load Sharing
    By multihoming, a site should be able to distribute both inbound and
    outbound traffic between multiple transit providers.  This goal is
    for concurrent use of the multiple transit providers, not just the
    usage of one provider over one interval of time and another provider
    over a different interval.

Therfore, I would like to know if this sentence "SHIM6 needs to avoid
sending packets concurrently over multiple path" means that SHIM6
doesn't support load sharing?

-Page9
    It is also necessary to
    track remote address information from the peer.  For instance, if the
    peer's currently used address is no longer in use, mechanism to relay
    that information is needed.  The Update message in the SHIM6 protocol
    is used for this purpose [I-D.ietf-shim6-proto].
What is "Update message"?
I can not find "Update message" in [I-D.ietf-shim6-proto] except an
Update Request message and an Update Acknowledgement message.
Therfore, I would like to know if they are the same thing.

If they are the same thing, to my understanding, I thinks the Update 
Request message and the Update Acknowledgement message only are used to 
inform a remote peer of local information, not to trace the remote peer 
status at all.
Right?

Cheers,
Deguang

Deguang Le schrieb:

> Hi all,
> A slight comments on draft-ietf-shim6-failure-detection-06.txt
> 
> -Page6
>       Note 2: In theory, it would also be possible for hosts to learn
>       about routing failures for a particular selected source prefix, if
>       only suitable protocols for this purpose existed.  Some proposals
>       in this space have been made, see, for instance
>       [I-D.bagnulo-shim6-addr-selection] and
>       [I-D.huitema-multi6-addr-selection], but none have been
>       standardized to date.
> 
> This paragraph shows [I-D.bagnulo-shim6-addr-selection] and 
> [I-D.huitema-multi6-addr-selection] are two unstandardized proposals for 
> local routing  failure detection.
> Then, I think the neighbour unreachability detection in [RFC2461] MAY be 
> a standardized proposal for this purpose.
> Right?
> 
> Cheers,
> Deguang
> 
> 
> 
> 
> Geoff Huston schrieb:
> 
>> Hi,
>>
>> This note starts the WG Last Call for comments on the three "base" 
>> Shim6 documents:
>>
>>
>> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim protocol"
>>  
>> draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>>
>> draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator 
>> Pair                                        Exploration Protocol for IPv6
>>                                        Multihoming"
>>
>> They can be found at:
>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>>    
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt 
>>
>>
>> Please review the documents carefully, and send your feedback to the 
>> SHIM6 list.  Please also indicate whether or not you believe that 
>> these documents
>> are ready to go to the IESG for publication as a set of Proposed 
>> Standards.
>>
>> This Working Group Last Call will end in two weeks, on the 12th 
>> October 2006 at 0800,  UTC+10
>>
>>
>>   Thanks,
>>
>>
>>         Geoff & Kurtis

Delivery-date: Thu, 28 Sep 2006 21:59:58 +0000
Date: Thu, 28 Sep 2006 23:58:56 +0200
From: Deguang Le <[email-masked]>
To:  [email-masked]
Subject: comments on draft-ietf-shim6-failure-detection-06.txt

Hi all,
A slight comments on draft-ietf-shim6-failure-detection-06.txt

-Page6
       Note 2: In theory, it would also be possible for hosts to learn
       about routing failures for a particular selected source prefix, if
       only suitable protocols for this purpose existed.  Some proposals
       in this space have been made, see, for instance
       [I-D.bagnulo-shim6-addr-selection] and
       [I-D.huitema-multi6-addr-selection], but none have been
       standardized to date.

This paragraph shows [I-D.bagnulo-shim6-addr-selection] and 
[I-D.huitema-multi6-addr-selection] are two unstandardized proposals for 
local routing  failure detection.
Then, I think the neighbour unreachability detection in [RFC2461] MAY be 
a standardized proposal for this purpose.
Right?

Cheers,
Deguang

Geoff Huston schrieb:

> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" 
> Shim6 documents:
> 
> 
> draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim protocol"
>  
> draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator Pair 
>                                        Exploration Protocol for IPv6
>                                        Multihoming"
> 
> They can be found at:
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>    http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
> 
> Please review the documents carefully, and send your feedback to the SHIM6 
> list.  Please also indicate whether or not you believe that these documents
> are ready to go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 12th October 
> 2006 at 0800,  UTC+10
> 
> 
>   Thanks,
> 
> 
>         Geoff & Kurtis

Delivery-date: Wed, 27 Sep 2006 05:50:51 +0000
Date: Wed, 27 Sep 2006 14:50:01 +0900
From: Shinta Sugimoto <[email-masked]>
To: <[email-masked]>
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

FYI,

you may find the IETF tools web page useful to check the
history of each document:

http://tools.ietf.org/wg/shim6/draft-ietf-shim6-proto/
http://tools.ietf.org/wg/shim6/draft-ietf-shim6-hba/
http://tools.ietf.org/wg/shim6/draft-ietf-shim6-failure-detection/

Regards,
Shinta

On Wed, 27 Sep 2006 08:23:57 +0300
<[email-masked]> wrote:

> Geoff,
> 
> Would it be possible to request a change log from the previous versions?
> That
> would be a help.
> 
> John
> 
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] On 
> >Behalf Of ext Geoff Huston
> >Sent: 27 September, 2006 07:35
> >To: [email-masked]
> >Cc: [email-masked]; Jari Arkko; Iljitsch van 
> >Beijnum; Marcelo bagnulo braun; Erik Nordmark
> >Subject: Shim6 Working Group Last call on the Shim6 Document Set
> >
> >Hi,
> >
> >This note starts the WG Last Call for comments on the three "base" 
> >Shim6 documents:
> >
> >
> >draft-ietf-shim6-proto-05.txt         "Level 3 multihoming 
> >shim protocol"
> > 
> >draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
> >
> >draft-ietf-shim6-failure-detection-06 "Failure Detection and 
> >Locator Pair 
> >                                       Exploration Protocol for IPv6
> >                                       Multihoming"
> >
> >They can be found at:
> >   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
> >   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
> >   
> >http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-de
> tection-06.txt
> >
> >Please review the documents carefully, and send your feedback 
> >to the SHIM6 list.  Please also indicate whether or not you 
> >believe that these documents are ready to go to the IESG for 
> >publication as a set of Proposed Standards.
> >
> >This Working Group Last Call will end in two weeks, on the 12th October
> >2006 at 0800,  UTC+10
> >
> >
> >  Thanks,
> >
> >
> >        Geoff & Kurtis
> >
> >
> >
> >

Delivery-date: Wed, 27 Sep 2006 05:24:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Shim6 Working Group Last call on the Shim6 Document Set
Date: Wed, 27 Sep 2006 08:23:57 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Geoff,

Would it be possible to request a change log from the previous versions?
That
would be a help.

John

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On=20
>Behalf Of ext Geoff Huston
>Sent: 27 September, 2006 07:35
>To: [email-masked]
>Cc: [email-masked]; Jari Arkko; Iljitsch van=20
>Beijnum; Marcelo bagnulo braun; Erik Nordmark
>Subject: Shim6 Working Group Last call on the Shim6 Document Set
>
>Hi,
>
>This note starts the WG Last Call for comments on the three "base"=20
>Shim6 documents:
>
>
>draft-ietf-shim6-proto-05.txt         "Level 3 multihoming=20
>shim protocol"
>=20
>draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"
>
>draft-ietf-shim6-failure-detection-06 "Failure Detection and=20
>Locator Pair=20
>                                       Exploration Protocol for IPv6
>                                       Multihoming"
>
>They can be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
>  =20
>http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-de
tection-06.txt
>
>Please review the documents carefully, and send your feedback=20
>to the SHIM6 list.  Please also indicate whether or not you=20
>believe that these documents are ready to go to the IESG for=20
>publication as a set of Proposed Standards.
>
>This Working Group Last Call will end in two weeks, on the 12th October
>2006 at 0800,  UTC+10
>
>
>  Thanks,
>
>
>        Geoff & Kurtis
>
>
>
>

Delivery-date: Wed, 27 Sep 2006 04:37:06 +0000
Date: Wed, 27 Sep 2006 14:35:08 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Shim6 Working Group Last call on the Shim6 Document Set
Cc: [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>

Hi,

This note starts the WG Last Call for comments on the three "base" 
Shim6 documents:

draft-ietf-shim6-proto-05.txt         "Level 3 multihoming shim protocol"
 
draft-ietf-shim6-hba-01               "Hash Based Addresses (HBA)"

draft-ietf-shim6-failure-detection-06 "Failure Detection and Locator Pair 
                                       Exploration Protocol for IPv6
                                       Multihoming"

They can be found at:
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
   http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt

Please review the documents carefully, and send your feedback to the SHIM6 
list.  Please also indicate whether or not you believe that these documents
are ready to go to the IESG for publication as a set of Proposed Standards.

This Working Group Last Call will end in two weeks, on the 12th October 
2006 at 0800,  UTC+10

  Thanks,

        Geoff & Kurtis

Delivery-date: Tue, 26 Sep 2006 15:25:19 +0000
To: [email-masked]
From: Victor Grishchenko <[email-masked]>
Subject: Some questions on shim6
Date: Tue, 26 Sep 2006 21:23:40 +0600

Good day!

I am a newbie here; I am not an expert in shim and, frankly, I am not  
much
involved with IPv6. Still, I am interested in this topic mostly on  
academic
grounds.

In particular, I have three questions.

1) Do you agree that shim6 is an "ad-hoc" (introduced to add multihoming
to IPv6)

2) Do you agree to the metaphor "shim6 is a kind of NAT inside the  
stack" ?

3) An alternate path of vectorizing TCP/UDP probably was considered in
the past. I mean, using multiple IPv6 addresses (a vector of) for a  
single
TCP connection; vectorizing all calculations performed by TCP. Do you  
have
any links to past proposals/discussions regarding this approach?

(As you may notice, I am skeptical on shim6.)

		Thanks in advance.

							Victor Grishchenko
							research fellow
							IPAM USU
							Yekaterinburg, Russia

Delivery-date: Tue, 19 Sep 2006 23:24:22 +0000
Date: Wed, 20 Sep 2006 02:22:38 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: Re: Specific problems in the Ericsson IPR statement?

I'm sending this e-mail just to let people know
that when I talked to the Ericsson IPR department
there were OK with the proposed change that
I described on the list earlier. They will update
the IPR declaration at the IETF site once its
clear that the WG is otherwise happy with
the protocol set.

--Jari

Delivery-date: Fri, 15 Sep 2006 07:18:07 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: www.shim6.org web page
Date: Fri, 15 Sep 2006 09:16:11 +0200

Hi,

we have set up a web page to post shim6 related information, including 
the related drafts, implementation efforts papers and links.

You can find at:

http://www.shim6.org

If you have any comments or any additional information that you think 
it would be useful to include there, please let me know.

Regards, marcelo

Delivery-date: Thu, 14 Sep 2006 01:12:32 +0000
Date: Thu, 14 Sep 2006 09:10:51 +0800
From: Sam Xia <[email-masked]>
Subject: RE: Specific problems in the Ericsson IPR statement?
To: 'Jari Arkko' <[email-masked]>, 'Jeroen Massar' <[email-masked]>
Cc: 'shim6' <[email-masked]>

Hi, Jari,
Since both Microsoft and Ericsson have announce their patent on CGA, it is
very important to know their attitues from both Microsoft and Ericsson.  I
have heard nothing from Microsoft is free except the patches of WiNDOWS. ):

 Best Regards, Sam Xia 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Monday, August 28, 2006 11:20 PM
> To: Jeroen Massar
> Cc: shim6
> Subject: Re: Specific problems in the Ericsson IPR statement?
> 
> Jeroen Massar wrote:
> 
> > Do I read it correctly that this says:
> >  - Company X has patent Z
> >  - Company X implements this thing
> >  - Ericsson implements thing with patent Z
> >  - Company X can't protect it's patent as it implement this.
> 
> No. I should have included all the details - actually company 
> X has a choice between 1. The free license, with an 
> implication to allow use of Z on the same terms, OR 2. the 
> default Ericsson IETF license which is so called RAND license 
> (reasonable and non-discriminatory). In the latter case there 
> is no impact on Z but the license isn't necessarily free.
> 
> Jim's issue was related to what you are asking. He wanted X 
> to be able to implement Shim6 for free if Z is in some 
> unrelated field, e.g., steam engines or CDMA radios. The 
> proposed change that I'll try to convince to my IPR 
> department to do means that this would be possible, as long 
> as X is not simultaneously requiring Ericsson to give
> Shim6 IPR for free and asking Ericsson to pay royalty for 
> some other IETF standards track RFC.
> 
> Just my interpretation, of course.
> 
> --Jari
> 
> 
> 

Delivery-date: Fri, 01 Sep 2006 08:29:20 +0000
Date: Fri, 01 Sep 2006 10:28:10 +0200
From: Jeroen Massar <[email-masked]>
Organization: Unfix
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: Specific problems in the Ericsson IPR statement?
OpenPGP: id=333E7C23
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAMFBMVEVdMCzbmJGsZlhiV3T5 6d9cSmS5f3/kvrwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuxjs+AAAACXBIWXMAAAsTAAALEwEA mpwYAAACNklEQVR42m1Sy27bMBBcyNAHUDCUq7xsmGshgrq3EOKrIII9VzTKDyjc5vc7u5ScBOjC z52dmX2I2qQRUogx4p2CfiSq6SBIUDxUrAIJ1fLfy7eXn5GWXUn+ab6qBWVEEQt+z8tX8KR5TTzD G6QQ9ZNaqfeiNnKxEURRVIaqptA0zJy8lAMTRvVAlnNLKSrDR2Wk0CJNeNFJ6xGk9Qsh3RANRKnm tasQFqQa1CPa6CvQihQhzcOgQHgwBFiQrww6GFDyn4AUHwBsTtJVjda/S4Vl/R+AO6wyNQ8f26Kk h1vZ5R2gg4HlpIU1PrZV221kHwAasB4e2BiaInXhbXhnyNbbymB2lXFTwAdIDcxd1s5OSriRXDup SgHWH0CVishxcZxNB4tx2qWil7m5h1IejjGsSHm566W4osPH0fupmnuPXkvpC7uf1I7alKcoALSQ L1wwvFdkwo0RQXbVlwygiSI0+Qp8xeClK64ThhVk3A/WikkuBgCj3elgWHaugCDA6RNj5exyuZgO /YIBd4qhAhAqZhMTtvYmu9JBR2i5izE9y5M3glS3P47P7LbtAoDkANbWOSyQ1ZVOGJgEJzgYwuHc m81kfVLZ3kjqvawB9saYrj5Gq6VV6/2ERW1GtEqH+54mkZpG/+N8zbnvgZhz9/KdWls9pvv8LWMj iKe331/mPwBCzc/XXDZoPc3z68s8/8oE6+k8A4AJCCiZpazIiVExv90LJhRCjVd42PMVJfe/0tX1 AOZ/QEHqFM0e9EMAAAAASUVORK5CYII=

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1D703E3329F8EAA6AE0EF5E0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Jari Arkko wrote:
> Jeroen Massar wrote:
>=20
>> Do I read it correctly that this says:
>>  - Company X has patent Z
>>  - Company X implements this thing
>>  - Ericsson implements thing with patent Z
>>  - Company X can't protect it's patent as it implement this.
>=20
> No. I should have included all the details - actually
> company X has a choice between 1. The free license,
> with an implication to allow use of Z on the same terms,
> OR 2. the default Ericsson IETF license which is so called
> RAND license (reasonable and non-discriminatory). In
> the latter case there is no impact on Z but the license
> isn't necessarily free.
>=20
> Jim's issue was related to what you are asking. He
> wanted X to be able to implement Shim6 for free if
> Z is in some unrelated field, e.g., steam engines
> or CDMA radios. The proposed change that I'll
> try to convince to my IPR department to do means
> that this would be possible, as long as X is
> not simultaneously requiring Ericsson to give
> Shim6 IPR for free and asking Ericsson to pay
> royalty for some other IETF standards track
> RFC.

That sounds very reasonable to me.

Maybe to solve all these IPR constructs, would it be an idea to have a=20
"IETF IPR" document; aka a document which states that "when using a IETF =

standards track document that one can't sue/pay royalties concerning any =

of the other companies that have a IETF standards track document=20
involving an IPR". (But then worded correctly ;) IANAL etc.

Greets,
  Jeroen

--------------enig1D703E3329F8EAA6AE0EF5E0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig1D703E3329F8EAA6AE0EF5E0--