Re: [icnrg] IRSG review of draft-irtf-icnrg-pathsteering

Thanks a ton for the review, Brian!

On 4 May 2023, at 14:52, Brian Trammell (IETF) wrote:

> Greetings,
>
> I’ve reviewed draft-irtf-icnrg-pathsteering for the IRSG.
>
> IMO this document is ready for an IRSG ballot, with nits.
>
> It describes a fairly straightforward way to add path awareness to 
> (path-symmetric) CCNx (as an example of ICN approaches). It has 
> somewhat less stringent security properties than other approaches in 
> the path-aware networking space (e.g. SCION), but this seems perfectly 
> reasonable in the ICN space.
>
> This document could be seen as “glue” between ICNRG and PANRG 
> (note: I’m saying this with my PANRG chair hat off). At the risk of 
> making an obligatory “you didn’t cite the reviewer” comment, 
> which you can feel free to ignore, the document clearly answers the 
> second and third questions (path discovery and selection, here called 
> “steering”) posed by RFC 9217 (“Current Open Questions in 
> Path-Aware Networking”) in an ICN context. I find it interesting 
> that no mention was made of the first question (i.e., which properties 
> of a path would a consumer use to make a decision about which paths to 
> use?), aside from a mention in the abstract of potential uses. Given 
> that the document essentially shows how to implement an externally 
> specified design within CCNx, this is possibly reasonable, but might 
> be worth addressing.
>
Good point. We obliquely talk about this in the introductory sections 
about the experimental nature of this specification and what experiments 
it enables, specifically things like network instrumentation and 
multi-path congestion control. Would it make sense to add a sentence or 
two to say that experimenting with paths having different properties is 
also a good goal for research using the defined protocol machinery? 
Happy to do that, and explicitly reference RFC9127.

One nuance compared to other PAN approaches is that this piggybacks path 
discovery on the base ICN data exchange, rather than having a separate 
path advertisement/discovery mechanism. That means when the recorded 
path comes back in an ICN Data message response, the properties of the 
path are known only implicitly to the consumer as opposed to being 
explicitly labeled. That makes the question of what properties a 
consumer uses to choose a path one of observation/measurement rather 
than advance selection based on an explicit advertised property (e.g ala 
SCION). Is this perhaps worth mentioning? I’m not sure.

> I have one editorial nit:
>
> typo “in roder that the forwarders use that path” -> “in 
> order”
Can fix now or wait for RFCed. Will fix if folks think an updated draft 
is appropriate prior to IRSG ballot.

>
> Thanks, cheers,
>
> Brian
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
DaveO