[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review comments on draft-ietf-shim6-proto-03.txt
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
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
- 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
6 - Section3 - Assumptions
I suspect that we assume that there are no IPv6 NATS on the path -
perhaps this should be explicitly stated
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.
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
- allowing external triggers for locator preference and locator switch
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
does not use the shim.</t>