Subject: [PANRG] I-D Action: draft-irtf-panrg-questions-10.txt

From: [email-masked]
Date: Mon, 11 Oct 2021 06:33:11 -0700

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           : Current Open Questions in Path Aware Networking
        Author          : Brian Trammell
	Filename        : draft-irtf-panrg-questions-10.txt
	Pages           : 10
	Date            : 2021-10-11

Abstract:
   In contrast to the present Internet architecture, a path-aware
   internetworking architecture has two important properties: it exposes
   the properties of available Internet paths to endpoints, and provides
   for endpoints and applications to use these properties to select
   paths through the Internet for their traffic.  While this property of
   "path awareness" already exists in many Internet-connected networks
   within single domains and via administrative interfaces to the
   network layer, a fully path-aware internetwork expands these concepts
   across layers and across the Internet.

   This document poses questions in path-aware networking open as of
   2021, that must be answered in the design, development, and
   deployment of path-aware internetworks.  It was originally written to
   frame discussions in the Path Aware Networking proposed Research
   Group (PANRG), and has been published to snapshot current thinking in
   this space.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-irtf-panrg-questions-10.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-panrg-questions-10

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Mon, 11 Oct 2021 13:49:48 +0000

Hi Brian, all, 

When checking the diff, I'm not sure to parse what is meant by "control plane address". Do you mean "some kind of locator"? something else?

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce <[email-masked]> De la part de internet-
> [email-masked]
> Envoyé : lundi 11 octobre 2021 15:33
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-irtf-panrg-questions-10.txt
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Oct 2021 10:43:05 -0500

Hi, Brian, and *my apologies to Theresa in advance,*

On Mon, Oct 11, 2021 at 8:51 AM <[email-masked]> wrote:

> Hi Brian, all,
>
> When checking the diff, I'm not sure to parse what is meant by "control
> plane address". Do you mean "some kind of locator"? something else?
>

I swear, I was trying to help, with what follows ...

One reasonable response to Med's reasonable question would be "I mean what
appears in
https://datatracker.ietf.org/doc/html/draft-irtf-panrg-path-properties-03,
but a quick scan of that draft (also an RG draft, of course) for "plane"
pops up these two occurrences:

   Entity:  A physical or virtual device or function, or a collection of
      devices or functions, which can, for example, process packets,
      measure path properties, or access information about paths.  With
      respect to a given communication, an entity may be on the *data*
*      plane* or *control plane*, and it may be on-path or off-path.

with no further definitions.

Given that we do have the path-properties draft, and that Med's question is
reasonable, and other PANRG drafts may also use control plane/data plane
terminology, would it also be reasonable to define those terms in
path-properties, so that they mean what we intend them to mean?

Best,

Spencer

Cheers,
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Oct 2021 11:09:23 -0500

Brian, I have a ridiculously small suggestion, which you could sit on until
AUTH48, if it seems appropriate. It really is that small.

> https://www.ietf.org/archive/id/draft-irtf-panrg-questions-10.html

While looking over -10 (as shepherd), I noticed that the subsections in
section 2 follow this structure:

   - Brief subsection title that gestures toward a question
   - Exposition about the question
   - The question, expressed as a complete sentence.

It's not easy to spot the question, expressed as a complete sentence,
unless you know what you're looking for. I'm only realizing this now,
because I've seen versions of these questions in Powerpoint so many times,
so I know what to look for (at the bottom of each slide).

I wonder if this would be clearer, as

   - Brief subsection title that gestures toward a question
   - The question, expressed as a complete sentence.
   - Exposition about the question

So, instead of

2.1. A Vocabulary of Path Properties

In order for information about paths to be exposed to an endpoint, and for
the endpoint to make use of that information, it is necessary to define a
common vocabulary for paths through an internetwork, and properties of
those paths. The elements of this vocabulary could include terminology for
components of a path and properties defined for these components, for the
entire path, or for subpaths of a path. These properties may be relatively
static, such as the presence of a given node or service function on the
path; as well as relatively dynamic, such as the current values of metrics
such as loss and latency.

This vocabulary must be defined carefully, as its design will have impacts
on the expressiveness of a given path-aware internetworking architecture.
This expressiveness also exhibits tradeoffs. For example, a system that
exposes node-level information for the topology through each network would
maximize information about the individual components of the path at the
endpoints, at the expense of making internal network topology universally
public, which may be in conflict with the business goals of each network's
operator. Furthermore, properties related to individual components of the
path may change frequently and may quickly become outdated. However,
aggregating the properties of individual components to distill end-to-end
properties for the entire path is not trivial.

The first question: how are paths and path properties defined and
represented?

Each section would look like this:

2.1. A Vocabulary of Path Properties

The first question: how are paths and path properties defined and
represented?

In order for information about paths to be exposed to an endpoint, and for
the endpoint to make use of that information, it is necessary to define a
common vocabulary for paths through an internetwork, and properties of
those paths. The elements of this vocabulary could include terminology for
components of a path and properties defined for these components, for the
entire path, or for subpaths of a path. These properties may be relatively
static, such as the presence of a given node or service function on the
path; as well as relatively dynamic, such as the current values of metrics
such as loss and latency.

This vocabulary must be defined carefully, as its design will have impacts
on the expressiveness of a given path-aware internetworking architecture.
This expressiveness also exhibits tradeoffs. For example, a system that
exposes node-level information for the topology through each network would
maximize information about the individual components of the path at the
endpoints, at the expense of making internal network topology universally
public, which may be in conflict with the business goals of each network's
operator. Furthermore, properties related to individual components of the
path may change frequently and may quickly become outdated. However,
aggregating the properties of individual components to distill end-to-end
properties for the entire path is not trivial.

Does this seem helpful?

Best,

Spencer

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 12 Oct 2021 10:58:11 +0200

hi Spencer,

Yep, that's better. Will push it to working copy but hold for auth48.

Thanks, cheers,

Brian

> On 11 Oct 2021, at 18:09, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Brian, I have a ridiculously small suggestion, which you could sit on until AUTH48, if it seems appropriate. It really is that small. 
> 
> While looking over -10 (as shepherd), I noticed that the subsections in section 2 follow this structure:
> 	• Brief subsection title that gestures toward a question
> 	• Exposition about the question
> 	• The question, expressed as a complete sentence. 
> It's not easy to spot the question, expressed as a complete sentence, unless you know what you're looking for. I'm only realizing this now, because I've seen versions of these questions in Powerpoint so many times, so I know what to look for (at the bottom of each slide). 
> 
> 	• Brief subsection title that gestures toward a question
> 	• The question, expressed as a complete sentence. 
> 	• Exposition about the question
> So, instead of 
> 
> In order for information about paths to be exposed to an endpoint, and for the endpoint to make use of that information, it is necessary to define a common vocabulary for paths through an internetwork, and properties of those paths. The elements of this vocabulary could include terminology for components of a path and properties defined for these components, for the entire path, or for subpaths of a path. These properties may be relatively static, such as the presence of a given node or service function on the path; as well as relatively dynamic, such as the current values of metrics such as loss and latency.
> 
> This vocabulary must be defined carefully, as its design will have impacts on the expressiveness of a given path-aware internetworking architecture. This expressiveness also exhibits tradeoffs. For example, a system that exposes node-level information for the topology through each network would maximize information about the individual components of the path at the endpoints, at the expense of making internal network topology universally public, which may be in conflict with the business goals of each network's operator. Furthermore, properties related to individual components of the path may change frequently and may quickly become outdated. However, aggregating the properties of individual components to distill end-to-end properties for the entire path is not trivial.
> 
> The first question: how are paths and path properties defined and represented?
> 
> The first question: how are paths and path properties defined and represented?
> 
> In order for information about paths to be exposed to an endpoint, and for the endpoint to make use of that information, it is necessary to define a common vocabulary for paths through an internetwork, and properties of those paths. The elements of this vocabulary could include terminology for components of a path and properties defined for these components, for the entire path, or for subpaths of a path. These properties may be relatively static, such as the presence of a given node or service function on the path; as well as relatively dynamic, such as the current values of metrics such as loss and latency.
> 
> This vocabulary must be defined carefully, as its design will have impacts on the expressiveness of a given path-aware internetworking architecture. This expressiveness also exhibits tradeoffs. For example, a system that exposes node-level information for the topology through each network would maximize information about the individual components of the path at the endpoints, at the expense of making internal network topology universally public, which may be in conflict with the business goals of each network's operator. Furthermore, properties related to individual components of the path may change frequently and may quickly become outdated. However, aggregating the properties of individual components to distill end-to-end properties for the entire path is not trivial.
> 
> Does this seem helpful?
> 
> Best,
> 
> Spencer

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 12 Oct 2021 10:59:34 +0200

hi Med,

By "control plane address" I mean "BGP AS number or equivalent in non-BGP interdomain routing protocols"; I guess "a locator" could be better as long as that doesn't imply LISP. Is there some other better term I could use?

Thanks, cheers,

Brian

> On 11 Oct 2021, at 15:49, [email-masked] wrote:
> 
> Hi Brian, all, 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 Oct 2021 10:17:34 +0100

I think you possibly mean "routing domain identifier".

A

-----Original Message-----
From: Panrg <[email-masked]> On Behalf Of Brian Trammell (IETF)
Sent: 12 October 2021 10:00
To: Mohamed Boucadair <[email-masked]>
Cc: [email-masked]
Subject: Re: [PANRG] I-D Action: draft-irtf-panrg-questions-10.txt

hi Med,

Thanks, cheers,

Brian

---

From: <[email-masked]>
Date: Tue, 12 Oct 2021 10:49:18 +0000

Hi Brian, 

Thanks for clarifying. 

Locator is not specific to LISP as LISP uses a better name: RLOC (Routing Locator). However, an RLOC is defined explicitly as an IP address... which is restrictive.    

I see that Adrian suggested "routing domain identifier". That works for me.

Cheers,
Med

> De : Brian Trammell (IETF) <[email-masked]>
> Envoyé : mardi 12 octobre 2021 11:00
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [PANRG] I-D Action: draft-irtf-panrg-questions-10.txt
> 
> hi Med,
> 
> By "control plane address" I mean "BGP AS number or equivalent in non-BGP
> interdomain routing protocols"; I guess "a locator" could be better as
> long as that doesn't imply LISP. Is there some other better term I could
> use?
> 
> Thanks, cheers,
> 
> Brian
> 
> >> De : I-D-Announce <[email-masked]> De la part de
> >> internet- [email-masked] Envoyé : lundi 11 octobre 2021 15:33 À :
> >> [email-masked] Cc : [email-masked] Objet : I-D Action:
> >> draft-irtf-panrg-questions-10.txt
> >>
> >>
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
> les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 12 Oct 2021 13:31:04 +0200

hi Adrian,

Yep, that's better. Will change, thanks!

Cheers,

Brian

> On 12 Oct 2021, at 11:17, Adrian Farrel <[email-masked]> wrote:
>