RE: I-D ACTION:draft-ietf-shim6-applicability-01.txt

[Sam Xia <xiazhongqi@huawei.com>]

Hi, Marchlo, 
   I think it is good to add the definition of Re-homing.

 Best Regards, Sam Xia 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, June 14, 2006 3:03 PM
> To: Iljitsch van Beijnum
> Cc: shim6-wg
> Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
> 
> Hi Iljitsch,
> 
> 
> thanks for your detailed comments...
> 
> some replies below...
> 
> El 13/06/2006, a las 16:52, Iljitsch van Beijnum escribió:
> 
> > On 8-jun-2006, at 1:28, Geoff Huston wrote:
> >
> >> This document discusses the applicability of the Shim6 
> IPv6 protocol
> >>    element and associated support protocols to provide site 
> >> multihoming
> >>    capabilities in IPv6.
> >
> > Comments:
> >
> > "While the Shim6 protocol does not impose any requirements on the
> >    disposition of the locators involved in this process"
> >
> > I don't understand what the authors are getting at here. I would 
> > strongely suggest actually mentioning the requirements that aren't 
> > imposed.
> >
> 
> the point being made in the sentence is that it would be 
> enough that one of the peers has multiple addresses in order 
> to be able to use the
> shim6 protocol, no matter what those addresses are. In 
> particular is not strictly required that those addresses come 
> from different isp (as it is somehow the scenario for which 
> the shim6 was designed for). It would be possible to use the 
> shim6 protocol in a host that has multiple interfaces with 
> one address in each interface and all the addresses with the 
> same prefix for instance... i guess you know all this 
> already, but this is what the draft is trying to communicate 
> (unsuccessfully it seems :-(
> 
> would it improve rephrasing it as:
> 
>    While the Shim6 protocol does not impose any requirements
>    on the addresses involved in this process
> 
> 
> > "In the scenario illustrated in Figure 1 host H 
> communicates with some
> >    remote host H'."
> >
> > My understanding of using a ' to differentiate between two 
> things is 
> > that it generally means that the two things are very similar, or 
> > represent two stages of the same thing. In this case, that doesn't 
> > apply so it's confusing. Please use another letter for the second 
> > host.
> >
> 
> :-)
> 
> will ddo
> 
> > In general, the document seems to assume understanding of 
> inter-domain 
> > routing. It is not explained what a locator is except that 
> on second 
> > use it says "locator (address)" which implies that the two are the 
> > same thing. ULID isn't explained.
> >
> 
> ok, we can add a definition section and include those two... 
> is there any other term that you think should be there?
> 
> > "The Shim6 protocol has other potential applications beyond site
> >    multi-homing.  For example, since Shim6 is a host-based 
> protocol, it
> >    can also be used to support session mobility between 
> interfaces on a
> >    multi-homed host."
> >
> > I disagree because shim6 isn't built to support jumping to a 
> > previously unknown address, it is assumed that the addresses to be 
> > used after a failure are known before the failure.
> >
> 
> well, you could send an UPDATE message from the new location 
> with the new locator and the validation information for it 
> included in the UPDATe message itself. There is no 
> fundamental reason why this cannot be done (we would need to 
> see the actual details of the protocol for this in any case...)
> 
> > Again my usual dislike of empty lines to skip to the next 
> "page" for a 
> > new heading.
> >
> 
> next one will be a "comptact" version....
> 
> > "   The Shim6 protocol is defined only for IPv6.  However, 
> there is no
> >    fundamental reason why a Shim6-like approach could not 
> support IPv4
> >    addresses as locators, either to provide multi-homing support to
> >    IPv4-numbered sites"
> >
> > We're already running out of IPv4 addresses with ONE address per 
> > host...
> >
> 
> fundamental reason from the protocol prespective... do you 
> want us to change something here?
> 
> > "   The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
> >    encoding information in the lower 64 bits of locators.  
> This imposes
> >    the requirement on address assignment to Shim6-capable 
> hosts that 
> > all
> >    interface addresses should be able to accommodate 64-bit 
> interface
> >    identifiers.  This requirement is also imposed by CGA [RFC3972]."
> >
> > Not to mention RFC 3513:
> >
> > "   For all unicast addresses, except those that start with binary 
> > value
> >    000, Interface IDs are required to be 64 bits long and to be
> >    constructed in Modified EUI-64 format."
> 
> ok, will add the reference
> 
> >
> > "4.  Shim6 Capabilities
> >
> > 4.1.  Fault Tolerance
> >
> > 4.1.1.  Establishing Communications After an Outage"
> >
> > Having headers without any text under them is considered bad style.
> >
> > "   managed centrally."
> >
> > A single line on a new "page" is a "widow" and considered 
> undesirable. 
> > Simarly, the following line is an "orphan":
> >
> > "   So, in this configuration, the shim6 protocol is used 
> to provide"
> >
> 
> i guess this will be solved with the compact version...
> 
> 
> > "However, MIPv6 lacks
> >    of failure detection mechanisms"
> >
> > Grammar.
> >
> > "In this case, the shim6
> >    protocol wouldn�t be used"
> >
> > Unicode problem??
> >
> 
> i think it is a typo
> 
> > Extra space after each sentence.
> >
> > Altough I feel there are way too many RFCs already, it 
> might make more 
> > sense to move the shim6/MIPv6 interactions to a separate document 
> > because this part just doesn't seem to feel at home here.
> >
> 
> well, the whole part about interactions with other parts of 
> the stack seems to belong to this document to me but perhaps 
> we can hear other opinions...
> 
> > Inconsistent use of "Shim6" and "shim6".
> >
> > "It is
> >    recommended that Shim6 is not used for SCTP sessions, 
> and that path
> >    maintenance is provided solely by SCTP."
> >
> > Hm, I suspect that there are failure modes that aren't 
> handled well by 
> > SCTP that shim6 can handle.
> 
> i don't know...
> 
> perhaps unidirectional failures? shim6 can handle a 
> communication with two unidirectional address pairs.... i 
> don't know about sctp...
> 
> >  And AFAIK SCTP has no security to speak of.
> >
> 
> i don't know....
> 
> > "In this case, the shim6 protocol would be associated to the
> >    tunnel interface"
> >
> > Missing period.
> >
> > "6.  Security considerations
> >
> >    This section will be completed before publication is requested."
> >
> > How about completing it before review is requested?
> >
> 
> :-)
> 
> we do what we can....
> 
> > "   2.  Application scenarios  . . . . . . . . . . . . . . 
> . . . . . . 
> >  4
> >    3.  Address Configuration  . . . . . . . . . . . . . . . 
> . . . . .  
> > 6"
> >
> > Inconsistent capitalization, happens in multiple places.
> >
> > Choice of American/British spelling MAY be inconsistent, I spotted 
> > "behaviour" and "optimization".
> >
> 
> regards, marcelo
> 
> 
> 
> > Iljitsch
> >
> 
> 
>