Subject: [PANRG] Explicitly adding different contexts to the path properties draft

From: Cyrill Krähenbühl <[email-masked]>
Date: Fri, 12 Nov 2021 08:47:31 +0100

Dear PANRG,

Thanks for the interesting discussion in the PANRG meeting yesterday!

Regarding the context discussion for the path properties draft, my 
understanding is that we would describe all relevant entities (node, 
host, link, path element, path, ...) in different contexts, such as 
data- and control-plane.
However, I'm hesitant to try describing these contexts, since each 
path-aware technology potentially has a fundamentally different 
understanding of these contexts.

For example:
Is the control-plane managed by a controller (e.g., SDN), by a 
distributed path-vector algorithm (e.g., BGP), or by a combination of 
different approaches (e.g., SCION using distributed push-based + 
pull-based algorithms)?
For the data-plane, do we have regular (destination-based) routing, or 
source routing, and in that case, is it loose or strict source routing?
Also, do forwarding devices have (global) forwarding tables, or is 
forwarding state transmitted by the packet itself?

I don't see a satisfying way to describe these contexts without the 
danger of not including a potential future PAN technology.

My suggestion is to mention in the introduction that even for a single 
PAN technology, there might be different contexts (e.g., data- and 
control-plane) where the entities might have different behavior and 
properties.

Best,
  Cyrill

---

From: <[email-masked]>
Date: Fri, 12 Nov 2021 08:48:06 +0000

Hi Cyrill, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Panrg <[email-masked]> De la part de Cyrill Krähenbühl
> Envoyé : vendredi 12 novembre 2021 08:48
> À : [email-masked]
> Objet : [PANRG] Explicitly adding different contexts to the path
> properties draft
> 
> Dear PANRG,
> 
> understanding is that we would describe all relevant entities (node, host,
> link, path element, path, ...) in different contexts, such as
> data- and control-plane.
> However, I'm hesitant to try describing these contexts, since each path-
> aware technology potentially has a fundamentally different understanding
> of these contexts.
> 

[Med] I guess this is covered by Section 2.1. No?

> For example:
> Is the control-plane managed by a controller (e.g., SDN), by a distributed
> path-vector algorithm (e.g., BGP), or by a combination of different
> approaches (e.g., SCION using distributed push-based + pull-based
> algorithms)?

[Med] It depends whether exposing such "internals" is needed for path-awareness. I tend to think it isn't, but I may be wrong. 

> forwarding state transmitted by the packet itself?

[Med] For the last item, why this can't be expressed as "Protocol Features available" property?

> 
> I don't see a satisfying way to describe these contexts without the danger
> of not including a potential future PAN technology.
> 
> My suggestion is to mention in the introduction that even for a single PAN
> technology, there might be different contexts (e.g., data- and
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg

_________________________________________________________________________________________________________________________

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: Krähenbühl Cyrill <[email-masked]>
Date: Tue, 16 Nov 2021 11:17:31 +0000

Hi Med,

Thank you for the comments.

See my responses inline.

> [Med] I guess this is covered by Section 2.1. No?

[CK] Partially yes, but maybe we could emphasize that even for a single PAN technology, different contexts, e.g., data- and control-plane, can use a different terminology in terms of nodes, links, and thus paths.

> [Med] It depends whether exposing such "internals" is needed for path-awareness. I tend to think it isn't, but I may be wrong.

[CK] I tend to think so as well.

In my opinion, in the case that a PAN technology wants to model these internals, this document should simply give them an appropriate path terminology and useful path properties to model such internals.

> [Med] For the last item, why this can't be expressed as "Protocol Features available" property?

[CK] I think you're right, packet-carried forwarding state could be expressed as a protocol feature of a node/path.

Best,
 Cyrill
________________________________
Von: [email-masked] <[email-masked]>
Gesendet: Freitag, 12. November 2021 09:48:06
An: Krähenbühl Cyrill; [email-masked]
Betreff: RE: [PANRG] Explicitly adding different contexts to the path properties draft

Hi Cyrill,

Please see inline.

Cheers,
Med