Re: Review comments on draft-ietf-shim6-proto-03.txt

[Erik Nordmark <erik.nordmark@sun.com>]

Geoff Huston wrote:
> So with my WG chair hat off, I've reviewed the protocol draft 
> (draft-ietf-shim6-proto-03.txt) and I have prepared a set of comments. 
> They are devided into general approach comments about document and 
> editorial nits.

Thanks very much for your comments (and the editorial nits you sent us 
off line). They'll help make the document clearer.

> 1 - Protocol Overview vs Protocol Specification
>
> I was confused whether section 4 is a part of the actual protocol 
> specification or whether it was a more general set of overview comments 
> about the characteristics of the particular approach described here. 
> What threw me was a number of MUSTs in section 2, which lead me th think 
> this was part of the specfication, while most of the section was of a 
> more discussive style.
>
> It appears that sections 7 through 14 are the actual protocol 
> specification, while section 4 is in deed a discussive section rather 
> than a specification.

Section 5 and 6 have normative parts as well.

> One way to clarify this would be to remove the RFC2460 MUSTS SHOULDs, 
> etc from section 4, and use an introductory sentence to note that this 
> is an informal overview of the protocol, and note that the protocol 
> specification is contained in the following sections.

I'll remove those from section 4. Perhaps there will be new 
subsection(s) in section 7 that have the normative parts.

> It may also be useful to encapsulate the current sections 7 though 14 
> into a single section 7 and call it "Protocol Specification", although 
> this is more of a personal style preference.

If we want to capture all the normative text, this would include section 
5, which already have section numbers with 3 parts (e.g., 5.14.1) which 
would end up with 4 parts. So I'd prefer not adopting that style.

> 2 - section 1.4 - Multicast
>
> Could this be better relocated into section 16 (Implicatons Elsewhere)? 
> with a single line statement in 1.2 ( Non-Goals) that IP multicast is 
> not supported in Shim6?

But I think multicast is supported; it just doesn't need locator 
rewriting because
 - the destination address is an identifier without location semantics 
(it is a multicast group)
 - the source address for multicast must be topologically correct for 
multicast routing (and RPF in particular) to work.

Thus there is no work the shim needs to do for a multicast packet.

That is a rather different statement than a simplistic "multicast is not 
supported". So having some text up front explaining this is needed.
(Whether the current text is good at explaining it is a separate matter.)

> 3 - section 1.5 renumbering implications
>
> Could this be better relocated into section 16 (Implications 
> Elsewhere?). It semes a better fit there than in section 1

Clearly this section is a bit of a misfit. Part of what it is saying is 
that there is an issue for further study whether or the shim should 
react to a ULID becoming invalid (due to its valid lifetime expiring) by 
blowing away the context.

Should we put that in "possible extensions"?

The non-goals section already says that we are not solving survivability 
across renumbering, which is all we need to say in section one.

> 4 - section 1.7 Traffic Engineering
>
> It may also be appropriate to include some considerations of traffic 
> engineering in section 19, and note in section 19 some of the issues 
> related to externally generated triggers for locator change and 
> externally-supplied locator preferences that would allow some form of TE 
> responses at a host.
>
> 5 - Section 3 - Assumptions
>
> The assumptions note the consideration of Ingress Filtering and 
> source-based path selection considerations, and appears to state the 
> same assumption twice. Perhaps an appendix should include further text 
> in the source address / site exit selection / path selection 
> considerations that are implictly assumed in this specification. It may 
> also be useful to reference some of the previous multi6 work on the 
> issues of source address section / site exit router selection.

I've rewritten this text to be more clear, and I've added a reference to 
draft-huitema-shim6-ingress-filtering.

> 6 - Section3 - Assumptions
>
> I suspect that we assume that there are no IPv6 NATS on the path - 
> perhaps this should be explicitly stated

Yes.

> 7 - Section 4.6 - comment on Mobile IPv6
>
> It may make sense to explicitly call out the "for further study" comment 
> in this section in section 19.

Yes.

> 8 - Section 8 - handling ICMP error messages
>
> It may be me, but I found this section somewaht opaque. Either a diagram 
> or some further text may help in terms of understanding what transforms 
> are to be applied to the ourter ICMP packet header locators and what 
> transforms are to be appied to the inner packet segment that is in the 
> payload of the ICMP packet.

I'll add a diagram and restructure the text a bit

> 9 - section 11 - Sending ULP payloads
>
> It is implied by the text here that if SHIM6 context reestablished use 
> of the initial locator pair as the current locators (ie. start with ULID 
> = locators, switch to new locators and then switch back to original ULID 
> = locator) then no packet transforms as specified in section 11.1 are 
> required. Should this be called out in the text?

I can certainly add that.

> As a meta consideration here, is there any logical reason to prefer the 
> initial ULIDs as locators?

The hosts have already used locators=ULIDs for the initial contact 
before the shim kicks in, and the context establishment will be done 
using those locators. Once the context is established the hosts can 
choose to switch, but such a switch isn't free; at a minimum the host 
has to verify that the peer is indeed present at the other locator by 
sending a probe packet (this is to avoid 3rd party flooding).

> 10 - section 19 Possible protocol extensions
>
> possible additional parts here could include:
>
> - allowing the API to trigger a locator change as well as locator 
> preference?

ok

> - allowing external triggers for locator preference and locator switch 
> (TE related)

Did you have anything more specific than the vague references to DHCP? 
This is what I currently have in my working copy:

  <t>Supporting the dynamic setting of locator preferences on a site-wide
basis, and use the Locator Preference option in the shim6 protocol to
convey these preferences to remote communicating hosts. This could mirror
the DNS SRV record's notion of priority and weight.</t>

  <t>Potentially recommend that more application protocols use DNS SRV
records to allow a site some influence on load spreading for the initial
contact (before the shim6 context establishment) as well as for traffic 
which
does not use the shim.</t>

   Erik