comments on draft-ggf-lwmcknight-wgissues-0

[Franco Travostino <travos@nortelnetworks.com>]

Hereafter my comments after reading your draft submission, and seeing
your presentation in Seattle (thanks!). An overarching comment: I believe
there is potential for you to have a mutually interesting collaboration
with a number of circles within GGF. To exploit this, the authors would
need to cleave out the relevant pieces. For instance, my first crack at a
breakup looks like:

• resource discovery topics, resource constrains, sharing protocol topics (see my earlier plug to the GS-Agreement Draft under different cover) belong to the SRM Area (GRAAP-WG in particular)
• "p2p-ness" topics belong to P2P Area
• a representative use-case of yours could land into the OGSA WG's collection of use cases
• networking-related topics including source-driven routing, resource-constrained protocol stacks and routing, NAT/firewall issues, high delay/jitter issues, in-network aggregation services belong to GHPN
• IPv6 topics (e.g., if every single byte counts due to BER and power, is there a way to drive the v6 flow-id as a mean to a particular end??) could fit the charter of an upcoming IPv6 working group (there was a BOF in Seattle)

I'd be glad to help you making the connections with these WG/RGs, if
you're so inclined. 

Detailed comments (which I penciled down before Seattle).

1) As we step into wireless --- i.e. un-tethered --- the scope can be
mighty broad. Hence the need to have some text around the scenarios of
interest. Is this work about cellular and Wi-Fi only? Does space
exploration fit your wireless grid definition? [A quip as I'm thinking
about this last point ... did Neil Armstrong and Apollo 11 give us a
first glimpse of grid-looking collaborative problem solving in 1969 ---
up until the instant that he switched the LM to manual, of course ;-) ]

2) Section 6, with regard to routing. I would add a couple of routing
variants with potential in this area, namely source-routing (i.e., source
defines the path through a field of devices/sensors) and
physical-distance based routing (e.g., GPSR). In your scenarios, I
believe that there is a role for one-to-many and anycast delivery
paradigms (though they are not in your text). If so, the routing
infrastructure must evolve accordingly.

3) Section 7. The digression on link-level security (as implemented via
WEP, TKIP, EAP) bears no relevance in this context, IMO.
Application-level security and selected instances of network-level
security (e.g., IPsec without ANY to ANY selectors) should be considered
instead, in that they cover end-to-end scope (or
end-to-aggregation-point, but more than one link anyhow). Some paragraphs
in 5.3, 5.5 highlight more interesting issues in security, and hint to
the role that user certificates can play for authN and authZ. As for
crypto techniques, the use of AES (section 7.2.2) has potential to reduce
power consumption (it can be more power-efficient than 3DES). AES can and
will be utilized in application-level and network-level security.
Luckily, this will happen under the covers, so there is no impact
whatsoever to a Grid infrastructure.

4) Section 8. I'm not sure whether the 'virtual market' (and the ensuing
P2P connotations) shapes the implementation of resource management (i.e.,
a decentralized one), or the application's style as well (i.e., the app
is akin to seti@home rather than a workflow).

5) Section 9.3.3. Admission control is yet another area ripe for
contributions, with intercepts into the SEC area (policy-based admission
control), Resource Management area (SLA considerations), and this very
forum for domain-specific (i.e., the network) considerations.


Franco Travostino
Director, Nortel Labs
Boston, MA