[icnrg] New version of icn-pathsteering posted to address comments form IRSG Poll

["David R. Oran" <[e-mail]>]

I just posted an update to
https://datatracker.ietf.org/doc/draft-irtf-icnrg-pathsteering/

which addresses the comments received during IRSG final poll. There were a couple of comments from Spencer Dawkins which did not result in any changes, so it would be helpful if Spencer could take a quick look at the attached email I sent a while back to make sure he’s ok with the author responses.

If everybody’s ok with this version, it should be ready to move to IESG conflict review.

DaveO

--- Begin Message ---

Spencer (et. al.),

Thanks for the helpful IRSG Poll comments on 
https://datatracker.ietf.org/doc/draft-irtf-icnrg-pathsteering/.

Here’s how we dealt with them:

	I'm a No Objection with a couple of comments, but I applaud ICNRG for 
taking this work on at all - I understand it's a difficult problem.

	I imagine many readers already know what a FIB is, but perhaps it 
should be expanded on first use.

Acronym expanded.

	I'm a little confused by error handling in 2.3. ISTM that what's being 
described is more like

	IF consumer has requested normal LNPM FIB lookup when an invalid path 
label is detected

	THEN do the normal lookup when an invalid path label is detected

	ELSE respond to the Interest with an Interest-Return

	Is that wrong? Perhaps this would be clearer if the order of the 
decisions were reversed in the text.

That’s right, but we wanted to highlight the basic case of doing 
Interest Return on detecting the bad path label error. We push 
describing the possibility of a consumer wanting to recover from this 
while still trying to steer the Interest to the second paragraph, since 
that’s where we introduce the notion of FALLBACK MODE.

I still like the current order of exposition, but if you think readers 
will be unduly confused I’m happy to revisit that. Let us know.

	But, ignoring that, why would responding to the Interest be a SHOULD? 
More succinctly, I read SHOULDs as MUST UNLESS - what foreseeable 
conditions would justify forwarder not responding to the Interest? And, 
of course, if the consumer hasn't requested normal LNMP FIB lookup, and 
the forwarder doesn't respond with an Interest Return, what is the 
effect of that decision - what happens next for the consumer, the 
forwarder, and the interest? Does the Interest just keep sending data 
that the forwarder doesn't forward?

It’s a SHOULD because in some implementations it may require more 
resources (particularly memory allocation) to produce an Interest Return 
than to simply drop the Interest. Now, the CCNx packet encoding is in 
fact VERY carefully constructed that you can take an Interest message 
and turn it into an Interest Return simply by overwriting a field and 
hence a good forwarder implantation SHOULD NOT need to drop it. 
Furthermore (again I’m pontificating on the careful design of CCNx) an 
Interest Return is deterministically no larger than an Interest, and in 
implementations that consider upstream bandwidth for returned data, it 
is guaranteed that the Interest Return not cause any link congestion on 
the reverse link. That said, since it is possible to have a forwarder 
that does drop Interests rather than than doing an Interest Return, we 
say SHOULD.

Now much if not all of this is covered (possibly implicitly) in RFC8609, 
and therefore Path steering does not introduce any new wrinkles other 
than the new error condition of an invalid path label. I didn’t make 
any edits to path steering. Do you think some more text is needed?

	In 2.5, "This should match the scalability of today's commercial 
routers that support up to 4096 physical and logical interfaces and 
usually do not have more than a few hundred active ones."

	is an assertion of fact - it should probably say "This matches the 
scalability of today's commercial routers that support up to 4096 
physical and logical interfaces and usually do not have more than a few 
hundred active ones.

Fixed.

I’ll wait to post the next version to see if you have more thoughts on 
your comments and my responses.


DaveO

--- End Message ---