Re: [Gen-art] Review: draft-garcia-shim6-applicability-03

Joel,

Writing as an interested party, not a reviewer:

On 2012-02-19 09:12, Joel M. Halpern wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-garcia-shim6-applicability-03
>     Applicability Statement for the Level 3 Multihoming Shim Protocol
>                                 (Shim6)
> Reviewer: Joel M. Halpern
> Review Date: 18-Feb-2012
> IETF LC End Date: 14-March-2012
> IESG Telechat date: N/A
> 
> Summary: This document is almost ready for publication as an information
> rfc
> 
> Major issues:
>     The third paragraph of the introduction makes assertions about PI
> based multihoming being "not generally available to end sites due to a
> strict policy of route aggregation in the DFZ."  As far as I know, this
> is simply not the case.  RIRs sell IPv6 PI for reasonable fees.  Most
> operators accept PI advertisements from customers.  And those
> advertisements are passed on to other ISP, and accepted.  I would
> recommend removal of the first sentence of this paragraph.  Instead, it
> needs to be noted that PI based multihoming can be done with IPv6, and
> then point to the scaling concerns.

Yes, the point is that PI doesn't scale to ten million sites,
but shim6 does. That should be clarified.

> 
> 
> Moderate Issues:
>     I am unable to understand the sentence "Shim6 has no means to
> enforce neither host nor network forwarding for a given locator to be
> used as source address."  I presume that what it is intended to
> communicate is simply a fact about shim6.  Please rewrite.

It's a fact. In fact, it's a fact that seriously impacts shim6
deployability, according to the experience of a student of mine.
Getting the appropriate locator pair out of a host, through the
appropriate edge router and ISP link, and through the firewall
at the far end, and doing the whole thing again in the reverse
direction, is a significant configuration challenge.

   Brian

> 
>     If I am reading section 7.1.1 on MobileIPv6/Shim6 interaction, it
> looks like you are describing a scenario in which the mobile node uses
> multiple HOAs as locators with a correspondent node.  I would suggest
> that this section would be clearer if the communicating parties were
> identified.  I suspect that the intended behavioral assumption is that
> the mobile node will register its CoA multiple times, once with each
> home address.  But this does not seem to be stated explicitly.
> 
> 
> Minor issues:
>     In th long comparative paragraph in the introduction, "The Shim6
> approach is thought to have better scaling properties with respect to
> the state held in the DFZ than the IPv approach." Could "IPv 4 approach
> be replaced with "PI approach"?
> 
>     In section 7.7 on the interaction with NPT66, I think it would be
> helped by a bit more discussion of when certain shim6 messages are
> exchanged, and which fields are validated.  Specifically, I can not tell
> if it is ever possible to get a shim6 ULID-pair option through an NPT66
> which is rewriting the one of the addresses prefixes in the packet.  I
> suspect not.  If indeed it just won't work, this needs to be stated MUCH
> more clearly.
> 
> Yours,
> Joel M. Halpern
> 
> 
> Nits/editorial comments:
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 