Re: [PANRG] [irsg] IRSG review request draft-irtf-panrg-questions-07

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Colin,

So, just to wrap this up with a bow ...

On Mon, Jun 21, 2021 at 4:50 PM Adrian Farrel <[e-mail]> wrote:

> Hi Spencer, Colin, RG,
>
>
>
> Spencer does a fine job of summarising the discussions that went on and to
> pointing up the changes to the document that resulted.
>
>
>
> To the first point, I think that it is good that 1.1 has more text on the
> definition of a “path” although (to me) it is unfortunate to dodge the
> question in this foundational document. If, as seems to be the case, the
> intention is to deliberately leave open to future research the meaning of
> “path” I feel that the document could more clearly articulate what it is
> about a path that is open for debate (i.e., explicitly pose the questions
> that the paragraph claims exist). I think that “technology dependent” may
> also be misleading if (as I believe is the intention) this definition is
> intended to apply at multiple layer of Ye Olde OSI Model.
>
>
>
> However, I also accept that, as I am not willing/able to invest
> significantly in helping to craft text and drive it to consensus, I should
> get out of the way.
>
>
>
> To the second point, the discussions of PCE were lengthy. It’s good that
> there is now a reference to 4655, but I wonder whether the text has simply
> introduced a new confusion: what is an endpoint? Is the end of a tunnel
> (i.e., a point of encapsulation or decapsulation) an endpoint? I would
> certainly argue it is. But, you see the problem with “endpoint”? Is it
> intended to mean “source of an IP packet”, in which case how does IP-in-IP
> relate? Is it intended to mean the source of the data flow (regardless of
> encapsulation) in which case it may extend beyond the IP domain. Or…
>
>
>
> And I would claim that a PCE is precisely an endpoint-exposed approach.
> But perhaps the new text in 1.1 is ambiguous?
>
> While
>
> there are technologies that attempt better-than-best-effort delivery,
>
> the interfaces to these are generally administrative as opposed to
>
> endpoint-exposed (e.g.  PCE [RFC4655] and SD-WAN approaches), and
>
> they are often restricted to single administrative domains.
>
> Does the “e.g.” apply to “generally administrative” or “endpoint-exposed”?
>
>
>
> But I agree that inspiring questions is the thing (we don’t do enough of
> that, IMHO), and without questions we can’t have answers. So, since this
> document clearly inspires me to ask more questions, it must be doing
> something right.
>

After chatting with Brian and with Jen, all of us think that Adrian is
pointing to a potential (and important, and worthwhile) *new *work item, as
we take the heavily transport-influenced
https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ and
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ forward
to understand how much these questions, and lessons, translate into other
levels of the protocol stack, including topics like tunneling and
encapsulation, path selection, and routing strategies.

After looking at the diffs from -07 to -09, I do think -09 gives enough
hints about this to encourage that work, and I note that it also dovetails
with some of the items that
https://datatracker.ietf.org/doc/html/draft-irtf-panrg-what-not-to-do-19#section-5
identifies as "Future Work", so I think it's fair to publish
https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ at this time.

So I think you can change the IRTF state from "Waiting for Document
Shepherd" to "Waiting for IRTF Chair".

Best,

Spencer


> Cheers,
>
> Adrian
>
>
>
>
>
> *From:* Panrg <[e-mail]> *On Behalf Of *Spencer Dawkins at
> IETF
> *Sent:* 21 June 2021 21:38
> *To:* Colin Perkins <[e-mail]>
> *Cc:* Ciavaglia, Laurent (Nokia - FR/Paris-Saclay) <
> [e-mail]>; Brian Trammell <[e-mail]>;
> [e-mail]; [e-mail]; The IRSG <
> [e-mail]>
> *Subject:* Re: [PANRG] [irsg] IRSG review request
> draft-irtf-panrg-questions-07
>
>
>
> Hi, Colin,
>
>
>
> On Mon, Jun 21, 2021 at 11:37 AM Colin Perkins <[e-mail]> wrote:
>
> Hi,
>
>
>
> There were some comments from Adrian Farrel in February - did they get
> addressed?
> https://mailarchive.ietf.org/arch/msg/panrg/w62vLVTaI-1Myr_u8jPUF8a0yRQ
>
>
>
> Colin
>
>
>
> I could reasonably let Brian answer this question, but if the shepherd
> should know the answer ...
>
>
>
> Adrian had two comments.
>
>
>
> The first one was about the definition of a path, and that also affected
> https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/. People
> might remember that we chased around this for a bit, because the definitive
> place where we defined terms was in
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/, which
> was expected to be requested for publication after both
> https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ and
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/. So we
> discussed adding normative references to both
> https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ and
> https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/, which was
> one way of resolving the comment, at the cost of holding both drafts in
> MISS-REF until
> https://datatracker.ietf.org/doc/draft-irtf-panrg-path-properties/ was
> also completed.
>
>
>
> So my understanding (and Brian can correct me) is that the changes between
> -07 and -09 in Section 1.1 are responsive to Adrian's comment. See
> https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-09.txt&url1=draft-irtf-panrg-questions-07.txt
> .
>
>
>
> Adrian's second comment, which was discussed in much more detail in
> private email that I happened to be copied on, was about the idea that
> (Spencer's paraphrase) PANRG is thinking about paths from an end-point's
> perspective, but there's also an inside-the-network way of thinking about
> paths, that's equally valid to think about, that includes what we commonly
> think of as routing, plus traffic engineering, tunneling, and several other
> aspects of packet forwarding.
>
>
>
>  We had two or three exchanges that were pretty interesting, but I think
> we left things with the idea that there may be a recursive situation going
> on, where a path is
>
>    - how you get from one host to another (which is mostly the way
>    PANRG people have thought about paths, as best I can tell), OR
>    - how you get from the edge router next to one host to either the edge
>    router next to the other host or the router next to the "next network on
>    the way to the other host", OR
>    - how you get from one core router to another core router, OR
>    - how you get from one physical layer box to another physical layer
>    box, OR
>    - well, it's just turtles all the way down.
>
> I don't think Brian, or I, thought that PANRG intentionally planned to
> exclude this layered view of paths, so the best way to take that forward
> was to start publishing drafts that explained how "path awareness" at
> various layers of the network was similar to, or different from, path
> awareness from host to host, and that ought to be in scope for PANRG.
>
>
>
> Brian, did I get that about right?
>
>
>
> Best,
>
>
>
> Spencer
>