comments on draft-ietf-shim6-failure-detection-06.txt {2}

[Deguang Le <le@cs.uni-goettingen.de>]

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