Subject: [PANRG] Missing review comments on draft-irtf-panrg-what-not-to-do-05 from Med Boucadair

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 12 Jan 2020 11:36:06 +0900

Ooops.

Med (and Theresa) pointed out that -06 did not include review comments from
Med (see below). Thank you both for the wake up call, and -07 will reflect
those comments.

My apologies for that. I'm at SA2 in South Korea this week, so probably
won't send -07 until next week, but it's coming.

Med had one meta-comment (below), that I'd like for the research group to
consider. Please see below.

Best,

Spencer

On Wed, Dec 11, 2019 at 6:24 PM <[email-masked]> wrote:

> Hi Spencer,
>
>
>
> Thank you for you effort on this document. I like the overall tone of the
> document.
>
>
>
> The document is about things to not (re)do. Those things would be much
> more clear if the readers have an idea of what we want to do at the first
> place with pan (not in term of solutions, but as design goals). I wonder
> whether some sort of priorities of pan design goals can be provided. See an
> example in Section 3.11 of RFC 6227.
>

I first thought about this comment as a review comment on our draft, but I
think it's more helpful to think about it as a new work item for the RG.
With that in mind,

If you don't (re)read RFC 6227, even taking a look at the table of contents
is helpful. See https://datatracker.ietf.org/doc/rfc6227/?include_text=1.

After that, please continue.

   - Theresa also asked (in her review comments) for a statement about what
   Path Aware Networking was (or was not). I added a new subsection in -06
   that was expanding on the first sentence in our charter, and that satisfied
   Theresa's comment, but she's an RG document editor, so people who haven't
   spent multiple years in PANRG would likely benefit from more explanation
   about the kinds of things people are currently trying to do with Path Aware
   Networking.
   - I think this would be extremely helpful in focusing the research group
   on our goals (this is also related to, but not the same as, our research
   problems, which also can focus us).
   - https://datatracker.ietf.org/doc/rfc6227/?include_text=1 is only 8
   pages long, and that covered all of Internet routing. I don't think a
   document about our current goals for Path Aware Networking would have to be
   any longer. Do others disagree?
   - https://datatracker.ietf.org/doc/rfc6227/history/ says it took about
   four years from -00 to approval as an RFC, but I don't think PANRG needs
   four years to produce a design goals document, for a variety of reasons. Do
   others disagree?

Is this something we should talk about in Vancouver?

>
>
>
> You may find some other few comments at:
>
>
>
> * pdf :
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-irtf-panrg-what-not-to-do-05-rev%20Med.pdf
>
> * doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-irtf-panrg-what-not-to-do-05-rev%20Med.doc
>
>
>
> Feel free to consider those comments as part of the Last Call.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Panrg [mailto:[email-masked]] *De la part de* Spencer
> Dawkins at IETF
> *Envoyé :* mardi 10 décembre 2019 23:21
> *À :* [email-masked]
> *Objet :* Re: [PANRG] I-D Action: draft-irtf-panrg-what-not-to-do-05.txt
>
>
>
> Dear PANRG,
>
>
>
> I believe this version of the draft reflects our conversations at IETF 105
> and 106, and is ready for Brian and Jan to request Last Call.
>
>
>
> Comments and corrections are always welcome, of course.
>
>
>
> Best,
>
>
>
> Spencer The Editor
>
>
>
> On Tue, Dec 10, 2019 at 4:16 PM <[email-masked]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Path Aware Networking RG RG of the IRTF.
>
>         Title           : Path Aware Networking: Obstacles to Deployment
> (A Bestiary of Roads Not Taken)
>         Author          : Spencer Dawkins
>         Filename        : draft-irtf-panrg-what-not-to-do-05.txt
>         Pages           : 34
>         Date            : 2019-12-10
>
> Abstract:
>    At the first meeting of the Path Aware Networking Research Group, the
>    research group agreed to catalog and analyze past efforts to develop
>    and deploy Path Aware technologies, most of which were unsuccessful,
>    in order to extract insights and lessons for path-aware networking
>    researchers.
>
>    This document contains that catalog and analysis.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-05
> https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-what-not-to-do-05
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg
>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Jan 2020 15:05:57 +0900

Dear PANRG,

I'm resending part of my first response to Med in a different thread,
because IMO it's not really about the draft he was commenting on, but is
important enough to (possibly) talk about in Vancouver. .

On Sun, Jan 12, 2020 at 11:36 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> If you don't (re)read RFC 6227, even taking a look at the table of
> contents is helpful. See
> https://datatracker.ietf.org/doc/rfc6227/?include_text=1.
>
>    - Theresa also asked (in her review comments) for a statement about
>    what Path Aware Networking was (or was not). I added a new subsection in
>    -06 that was expanding on the first sentence in our charter, and that
>    satisfied Theresa's comment, but she's an RG document editor, so people who
>    haven't spent multiple years in PANRG would likely benefit from more
>    explanation about the kinds of things people are currently trying to do
>    with Path Aware Networking.
>    - I think this would be extremely helpful in focusing the research
>    group on our goals (this is also related to, but not the same as, our
>    research problems, which also can focus us).

Thanks for your thoughts, of course!

Best,

Spencer

---

From: Theresa Enghardt <[email-masked]>
Date: Mon, 20 Jan 2020 17:01:35 +0100

Dear PANRG,

Some initial thoughts on this inline:

On 16.01.20 07:05, Spencer Dawkins at IETF wrote:
> On Sun, Jan 12, 2020 at 11:36 AM Spencer Dawkins at IETF
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>       * Theresa also asked (in her review comments) for a statement
>         about what Path Aware Networking was (or was not). I added a
>         new subsection in -06 that was expanding on the first sentence
>         in our charter, and that satisfied Theresa's comment, but
>         she's an RG document editor, so people who haven't spent
>         multiple years in PANRG would likely benefit from more
>         explanation about the kinds of things people are currently
>         trying to do with Path Aware Networking.
>
I noticed that it's not easy to find a clear problem statement for
PANRG, and that maybe makes it harder for people to understand our goals.

The parts that do exist are scattered across the charter and different
drafts.

For example, in the charter, the closest thing to a problem statement I
could find was "bringing path awareness to transport and application
layer protocols". The motivation is that because of "increased diversity
in access networks, paths can no longer be assumed to be "invisible,
homogenous, singular, with dynamics solely determined by the
connectivity of the endpoints and the Internet control plan".

Now while the motivation makes sense to me, I think the problem
statement is a bit vague: Why is it a problem if paths are different and
what do we want to achieve by knowing about and selecting a path? Better
security, whatever that means in a specific context? Better performance,
and for whom? Or something else? I think there's a diversity of possible
use cases here.

The Questions draft states as the definition (or goal?) of a path-aware
internetworking architecture that "endpoints have the ability to select
or influence the path through the network used by any given packet, and
the network and transport layers explicitly expose information about the
path or paths available between two endpoints to those endpoints and the
applications running on them, so that they can make this selection."

Also, the Questions draft implicitly contains at least some design
goals. For example, it mentions trustworthiness in multiple places, it
mentions scalability, it mentions deployment requirements. However, it
already indicates that there might not be a perfect solution, but
trade-offs, and the right answer may depend on context. (At least that's
what I'm reading into it.)

In addition, I guess some of the lessons in What-not-to-do can also be
rephrased as design goals.

While this is all quite general, the Path Properties draft contains more
specific use cases, such as Path Selection for security or performance
improvements, to motivate what properties it provides as examples. (Note
that us authors are currently in the process of reworking this section
though.)

>       * I think this would be extremely helpful in focusing the
>         research group on our goals (this is also related to, but not
>         the same as, our research problems, which also can focus us).
>
I agree that some focus would be useful. I'm just not sure if a generic
"PANRG Design Goals" document is the right thing to focus on.

>       * https://datatracker.ietf.org/doc/rfc6227/?include_text=1 is
>         only 8 pages long, and that covered all of Internet routing. I
>         don't think a document about our current goals for Path Aware
>         Networking would have to be any longer. Do others disagree?
>       * https://datatracker.ietf.org/doc/rfc6227/history/ says it took
>         about four years from -00 to approval as an RFC, but I don't
>         think PANRG needs four years to produce a design goals
>         document, for a variety of reasons. Do others disagree?
>
I think we could probably write something along these lines based on the
Questions draft and the What-not-to-do draft. I guess if we stick to the
generic problem statement, we pretty much agree what we want and this
will be quick and easy: Of course we want scalable, we want trustworthy,
we want deployable, etc.

However:

I think the actual trade-offs in these Design Goals, like some of the
answers to the questions in the Questions draft, depend on the specific
problem you are trying to solve. If our problem statement is too generic
or vague, I'm not sure we can produce much more useful content than we
already have in the existing drafts.

However, maybe it'd be interesting to write a draft on specific problem
statements within the scope of PANRG and then provide answers to some
design questions (like "how to achieve scalability" or "how scalable
does this need to be", "how to solve trust", ...) for this specific context.

Perhaps this could be the "What-to-do-instead" draft that somebody
mentioned some PANRG sessions ago?

But do we actually have any successfully deployed path-aware techniques
that we can point to and analyze? Or do we have to write science
fiction, which could also be interesting?

Just my 2 cents. Thanks for reading!

Best,
Theresa

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 21 Jan 2020 00:48:48 -0600

Theresa,

> Some initial thoughts on this inline:

Thanks for thinking!

I'm top-posting, because I'm not sure what I'm typing maps onto specific
text you typed (so inline isn't a great plan), but I definitely am reacting
to your comments below.

I could have done a better job of saying this in my note, but I'd guess a
PAN Design Goals draft wouldn't be as cohesive as
https://datatracker.ietf.org/doc/rfc6227/?include_text=1, precisely because
(as you said) we aren't all working on the same problems with the same
constraints. I think it would be OK to say "these are design goals that
people try to achieve", but not "these are design goals that you must try
to achieve to work in PANRG". So, agreed where you said things like that.

I'd guess doing a table of contents/skeleton would tell us a lot about
whether this could be a good idea. I'd be happy to work on that, and would
love to work on that with someone else. Anyone interested?

I think we can steal (some) stuff out of what-not-to-do and
research-questions, but it's good to remember that what-not-to-do isn't
THAT broad a survey (all the protocols listed passed through some version
of the IETF), and some of the contributions go back into the 1970s and
1980s, so we might be able to mine those drafts for a starting point, but
we could also ask "what are the design goals we should be working toward,
in research now?"

You asked "has anybody gotten this right yet?". What-not-to-do excluded
that question by definition, but perhaps we should be asking it now, and
looking outside the IETF experience (and if we had design goals, we'd know
whether someone's $MyCoolIdea actually was the kind of path aware
networking we are researching, which would help separate sheep from goats).

I absolutely agree that problem statements would be technique-specific - so
there wouldn't be a "PAN Problem Statement" draft. I think you're combining
two things - a clear definition of Path Aware Networking - which interacts
with our design goals - and a clear problem statement (or set of problem
statements), which interacts with our research questions. I agree that we
could use both.

I really like your invocation of "what-to-do-instead". People have been
asking for that, and we're headed the right direction towards being able to
say something intelligent.

Thanks again for your thoughts.

Best,

Spencer

>> I noticed that it's not easy to find a clear problem statement for PANRG,
> and that maybe makes it harder for people to understand our goals.
>
> could find was "bringing path awareness to transport and application layer
> protocols". The motivation is that because of "increased diversity in
> access networks, paths can no longer be assumed to be "invisible,
> homogenous, singular, with dynamics solely determined by the connectivity
> of the endpoints and the Internet control plan".
>
> Now while the motivation makes sense to me, I think the problem statement
> is a bit vague: Why is it a problem if paths are different and what do we
> want to achieve by knowing about and selecting a path? Better security,
> whatever that means in a specific context? Better performance, and for
> whom? Or something else? I think there's a diversity of possible use cases
> here.
>
>
> internetworking architecture that "endpoints have the ability to select or
> influence the path through the network used by any given packet, and the
> network and transport layers explicitly expose information about the path
> or paths available between two endpoints to those endpoints and the
> Also, the Questions draft implicitly contains at least some design goals.
> For example, it mentions trustworthiness in multiple places, it mentions
> scalability, it mentions deployment requirements. However, it already
> indicates that there might not be a perfect solution, but trade-offs, and
> the right answer may depend on context. (At least that's what I'm reading
> into it.)
>
>>    - https://datatracker.ietf.org/doc/rfc6227/history/ says it took
>>    about four years from -00 to approval as an RFC, but I don't think PANRG
>>    needs four years to produce a design goals document, for a variety of
>>    reasons. Do others disagree?
>>
> generic problem statement, we pretty much agree what we want and this will
> be quick and easy: Of course we want scalable, we want trustworthy, we want
> deployable, etc.
>
> However:
>
> problem you are trying to solve. If our problem statement is too generic or
> vague, I'm not sure we can produce much more useful content than we already
> have in the existing drafts.
>
> design questions (like "how to achieve scalability" or "how scalable does
> this need to be", "how to solve trust", ...) for this specific context.
>
> that we can point to and analyze? Or do we have to write science fiction,
> which could also be interesting?
>