Subject: [Raw] Call for adoption of draft-theoleyre-raw-oam-support-01

From: Rick Taylor <[email-masked]>
Date: Mon, 30 Mar 2020 10:13:36 +0000

Hi All,

The authors of: draft-theoleyre-raw-oam-support-01 (have asked for a call for working group adoption of their draft.

The link to the draft is: https://datatracker.ietf.org/doc/draft-theoleyre-raw-oam-support/

This is your opportunity to express your opinion.

A decision will be made on/after 13th April.

Cheers,

Rick and Eve
Co-chairs

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Mar 2020 11:10:30 +0000

I support the adoption. The draft already has a very good structure and content.

> -----Original Message-----
> From: RAW <[email-masked]> On Behalf Of Rick Taylor
> Sent: lundi 30 mars 2020 12:14
> To: [email-masked]
> Subject: [Raw] Call for adoption of draft-theoleyre-raw-oam-support-01
> 
> Hi All,
> 
> --
> RAW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/raw

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Mon, 30 Mar 2020 13:14:07 +0200

+1 as co-author.

Georgios

> On Mar 30, 2020, at 13:10, Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
>

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Mon, 30 Mar 2020 14:30:18 +0200

I support adoption.

Thanks,

Carlos

On Mon, Mar 30, 2020 at 1:14 PM Georgios Z. Papadopoulos <
[email-masked]> wrote:

> >> The authors of: draft-theoleyre-raw-oam-support-01 (have asked for a
> call for
> >> working group adoption of their draft.
> >>
> >> The link to the draft is:
> https://datatracker.ietf.org/doc/draft-theoleyre-raw-
> >> oam-support/
> >>

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Mon, 30 Mar 2020 14:34:17 +0200

I support the adoption of this draft. The content is well structured and
the scope is inline with the raw charter.
regards
X

Missatge de CARLOS JESUS BERNARDOS CANO <[email-masked]> del dia dl., 30

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

-- 

INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE 
CATALUNYA (UOC)

Us informem que les vostres dades identificatives i les 
contingudes en els missatges electrònics i fitxers adjunts es poden 
incorporar a les nostres bases de dades amb la finalitat de gestionar les 
relacions i comunicacions vinculades a la UOC, i que es poden conservar 
mentre es mantingui la relació. Si ho voleu, podeu exercir el dret a 
accedir a les vostres dades, rectificar-les i suprimir-les i altres drets 
reconeguts normativament adreçant-vos a l'adreça de correu emissora o a 
[email-masked] <mailto:[email-masked]>.

Aquest missatge i qualsevol 
fitxer que porti adjunt, si escau, tenen el caràcter de confidencials i 
s'adrecen únicament a la persona o entitat a qui s'han enviat.

Així 
mateix, posem a la vostra disposició un delegat de protecció de dades que 
no només s'encarregarà de supervisar tots els tractaments de dades de la 
nostra entitat, sinó que us podrà atendre per a qualsevol qüestió 
relacionada amb el tractament de dades. La seva adreça de contacte és 
[email-masked] <mailto:[email-masked]>.
INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE 
LA UNIVERSITAT OBERTA DE CATALUNYA (UOC)
Os informamos de que vuestros 
datos identificativos y los contenidos en los mensajes electrónicos y 
ficheros adjuntos pueden incorporarse a nuestras bases de datos con el fin 
de gestionar las relaciones y comunicaciones vinculadas a la UOC, y de que 
pueden conservarse mientras se mantenga la relación. Si lo deseáis, podéis 
ejercer el derecho a acceder a vuestros datos, rectificarlos y suprimirlos 
y otros derechos reconocidos normativamente dirigiéndoos a la dirección de 
correo emisora o a [email-masked] <mailto:[email-masked]>.
Este mensaje y 
cualquier fichero que lleve adjunto, si procede, tienen el carácter de 
confidenciales y se dirigen únicamente a la persona o entidad a quien se 
han enviado.
Así mismo, ponemos a vuestra disposición a un delegado de 
protección de datos que no solo se encargará de supervisar todos los 
tratamientos de datos de nuestra entidad, sino que podrá atenderos para 
cualquier cuestión relacionada con el tratamiento de datos. Su dirección de 
contacto es [email-masked] <mailto:[email-masked]>.

UNIVERSITAT OBERTA DE 
CATALUNYA (UOC) DATA PROTECTION INFORMATION
Your personal data and the data 
contained in your email messages and attached files may be stored in our 
databases for the purpose of maintaining relations and communications 
linked to the UOC, and the data may be stored for as long as these 
relations and communications are maintained. If you so wish, you can 
exercise your rights to access, rectification and erasure of your data, and 
any other legally held rights, by writing to the sender’s email address or 
to [email-masked] <http://[email-masked]>.
This message and, where 
applicable, any attachments are confidential and addressed solely to the 
individual or organization they were sent to.
The UOC has a data protection 
officer who not only supervises the data processing carried out at the 
University, but who will also respond to any questions you may have about 
this data processing. You can contact our data protection officer by 
writing to [email-masked] <http://[email-masked]>.

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Mon, 30 Mar 2020 19:54:22 +0200 (CEST)

Hi,

I also support this draft.

Best,
Aris

On Mon, Mar 30, 2020 at 2:34 PM Xavi Vilajosana Guillen <[email-masked]>
wrote:

> http://wine.rdi.uoc.edu <http://wine.rdi..uoc.edu>
> INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE CATALUNYA
> (UOC)
>
> Us informem que les vostres dades identificatives i les contingudes en els
> missatges electrònics i fitxers adjunts es poden incorporar a les nostres
> bases de dades amb la finalitat de gestionar les relacions i comunicacions
> vinculades a la UOC, i que es poden conservar mentre es mantingui la
> relació. Si ho voleu, podeu exercir el dret a accedir a les vostres dades,
> rectificar-les i suprimir-les i altres drets reconeguts normativament
> adreçant-vos a l'adreça de correu emissora o a [email-masked].
>
> Aquest missatge i qualsevol fitxer que porti adjunt, si escau, tenen el
> caràcter de confidencials i s'adrecen únicament a la persona o entitat a
> qui s'han enviat.
>
> Així mateix, posem a la vostra disposició un delegat de protecció de dades
> que no només s'encarregarà de supervisar tots els tractaments de dades de
> la nostra entitat, sinó que us podrà atendre per a qualsevol qüestió
> [email-masked].
> ------------------------------
> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE LA UNIVERSITAT OBERTA DE
> CATALUNYA (UOC)
> Os informamos de que vuestros datos identificativos y los contenidos en
> los mensajes electrónicos y ficheros adjuntos pueden incorporarse a
> nuestras bases de datos con el fin de gestionar las relaciones y
> comunicaciones vinculadas a la UOC, y de que pueden conservarse mientras se
> mantenga la relación. Si lo deseáis, podéis ejercer el derecho a acceder a
> vuestros datos, rectificarlos y suprimirlos y otros derechos reconocidos
> normativamente dirigiéndoos a la dirección de correo emisora o a
> [email-masked].
> Este mensaje y cualquier fichero que lleve adjunto, si procede, tienen el
> carácter de confidenciales y se dirigen únicamente a la persona o entidad a
> quien se han enviado.
> Así mismo, ponemos a vuestra disposición a un delegado de protección de
> datos que no solo se encargará de supervisar todos los tratamientos de
> datos de nuestra entidad, sino que podrá atenderos para cualquier cuestión
> relacionada con el tratamiento de datos. Su dirección de contacto es
> [email-masked].
> ------------------------------
> UNIVERSITAT OBERTA DE CATALUNYA (UOC) DATA PROTECTION INFORMATION
> Your personal data and the data contained in your email messages and
> attached files may be stored in our databases for the purpose of
> maintaining relations and communications linked to the UOC, and the data
> may be stored for as long as these relations and communications
> are maintained. If you so wish, you can exercise your rights to access,
> rectification and erasure of your data, and any other legally held rights,
> by writing to the sender’s email address or to [email-masked].
> This message and, where applicable, any attachments are confidential and
> addressed solely to the individual or organization they were sent to.
> The UOC has a data protection officer who not only supervises the data
> processing carried out at the University, but who will also respond to any
> questions you may have about this data processing. You can contact our data
> protection officer by writing to [email-masked].
>
> --
> RAW mailing list
> [email-masked]

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 30 Mar 2020 12:41:05 -0700

As I used to tell my thesis students (often), the pieces are there but
use the cut/paste features of your word processor and get them better
organized:

Organization.

Find a reliability engineering textbook (preferably one that predates
the internet). In it you will find that there are three principles of
high availability engineering:

1.  Principle: elimination of single points of failure.

in 2. you have "Fault-tolerance also assumes that multiple path have to
be provisioned ..."

5.1 and 5.2 also address the principle.

2.  Principle: reliable crossover.

This is not treated explicitly but is tacit within 5.2. Internet
Protocol executes the principle. The problem with this draft is it
advocates adding state into the routing fabric without seeming to
realize that that tends to defeat the reliable crossover principle. 5.3
resource reservation clearly does this. Therefore, I recommend that the
reliable crossover principle get explicit treatment at this stage so
the tradeoffs can be properly weighed.
  (We've gone through resource reservation protocols before -- remember
RSVP? -- and they've not been very successful).  

3.  Principle: detection of faults as they occur.

3.3 and 3.4 treat this, but, IMHO, the organization should again be
cleaned up.  Back in the days when Simple Network Management Protocol
was being worked up, a common acronym was FCAPS for [Fault Configuraion
Accounting Performance Security]. Sounds to me like a pattern that this
discussion could be mapped onto.
   In this case we have performance management solutions commingled
with fault management ones. My experience is that QoS issues should
always be the _last_ to be discussed, not the first.
   SNMP is nowhere mentioned in the draft. Sooner or later, you're
going to need gets, sets and traps.  Is now the right time?

Recommend that the organization be remapped onto the three principles.
Help me; is this posting supposed to ignite the discussion or does the
organization need to get straightened out first?  I certainly agree to
adoption in the former instance but not for the latter.

Nits.

5.1.  Multipath.  Definition is incorrect.
  - what you are looking for is alternate routes -- part of the
principle of elimination of single points of failure.
  - but 'multipath' in radio means multiple paths between an RF
transmitter and and RF receiver (such as GPS satellites and GPS
receivers, due to urban canyons). In radionavigation multipath is
always bad; in radio communication it's alsmost always bad. But it's
not the alternate routes you're after here. Since you are dealing with
radio as a subject, don't get the terminology confused.

Ping and Traceroute are indeed some of the earliest diagnostics in the
internet. But they only show you visible routers. If your path goes
through a VPN that won't show.

4. has both prior art and MAC issues.
  - MAC.  I use the term wireless LAN to denote those network segments
that reach from last router to end system (predominantly WiFi).  WiFi
uses a contention MAC that his highly sensitive to congestion -- 1) too
much traffic will jam the link, 2) the jamming occurs at low baseband
usage and 3) there's no way to control it.  
  Radio-WANs include radio networks in the interior of the internetwork
(the problem is router-router interconnect).  The successful protocols
in this topology have contention-free MACs (IEEE 802.16 and LTE). The
contention-free MAC is jam-proof, provides high bandwidth usage and is
eminently controllable.
  Prior art. IEEE 802.16 has about four dozen MAC messages listed in
the standard. Many are similar to what is in 4. now except with
different language.  Is it necessary to reinvent this?  Example:
'Received Signal Strength Indicator' and 'per radio channel to measure
e.g. the level of external interference, and to be able to apply
counter-measures' are mentioned. Ranging messages in IEEE 802.16
measure similar  (and somewhat more precisely defined) values both per
channel and per subscriber station. The 802.16 committee organized all
these values as a MIB which, of course, can be exported.  
  (I'm familiar with IEEE 802.16 but not with the text of LTE. Since
all the vendors that started building 802.16 hardware shifted to LTE
when the telcos adopted it (as '4G') I'm assuming that there's a good
deal of copying.)

On Mon, 2020-03-30 at 11:10 +0000, Pascal Thubert (pthubert) wrote:
> > The authors of: draft-theoleyre-raw-oam-support-01 (have asked for
> > a call for
> > The link to the draft is: https://datatracker.ietf.org/doc/draft-th
> > eoleyre-raw-
> > oam-support/
> >

---

From: Fabrice Theoleyre <[email-masked]>
Date: Tue, 31 Mar 2020 14:42:41 +0200

Dear Rex,

Thank you for your feedback. 

> going to need gets, sets and traps.  Is now the right time?

I agree with these 3 principles. 
We will try to think about how to highlight them clearly. 

Indeed, reliability is one criteria (we also have the delay). 
Thus, I would probably not structure the draft around these 3 topics. 

However, we will find a way to more clearly emphasize this distinction. 

> adoption in the former instance but not for the latter.

From my point of view: the objective is currently to initiate the discussion, determine what is missing, etc.

> radio as a subject, don't get the terminology confused.

Thank you for raising this possible source of confusion. Actually, we have two different concepts:
1/ multipath for radio propagation (multiple paths for the wave)
2/ multipath routing = multiple routing paths (multiple paths at the routing layer). Actually, multipath routing goes farther than an ”alternate route”, since packets may be dispatched along meshed multipath routes (i.e. we don’t have distinct end-to-end routes, with one primary path, and an alternate path). 

While the term ”multipath" is used in both domains, they have a different usage (they both mean multiple ”paths”, but for different things)/ 

To avoid any confusion, the draft now uses either ”multipath routing” or ”multipath propagation” and never ”multipath” alone. 

> through a VPN that won't show.

They correspond to usual OAM tools that we just cited. 
For RAW, we will need specific tools because of the wireless characteristics. 
 
We reformulated into "They help to identify a subset of the list of routers in the route” instead of "They help to identify the list of routers in the route”
Is it now clearer?

> when the telcos adopted it (as '4G') I'm assuming that there's a good

I’m not sure to understand this point. 

By MAC, I guess you mean Medium Access Control? 
Even if the MAC is collision free (as WiMAX, Wireless HART, etc.), you have a scheduler that allocates the transmission opportunities. 
In my mind, OAM is in charge of maintaining a view of the network and its ressource usage to help typically the scheduler. 

Thus, the section 4.1 tries for instance to highlight the statistics to report for this purpose. 
I guess that’s typically the things to highlight for RAW: wireless transmissions create specific concerns (e.g. using multiple radio channels to combat external interference for some technologies, as well as using different Spreading Factors, etc.)

In conclusion, I’m not sure to understand how the current text is in contradiction with the example you provide. 

Thank you for your constructive feedback!

Best regards,
Fabrice

NB: the last version of the draft (with our latest modifications) is available online at https://github.com/ftheoleyre/paw-oam/

---

From: Janos Farkas <[email-masked]>
Date: Tue, 31 Mar 2020 22:02:57 +0000

Hi,

I guess I'd start with:
3) Does the draft meet the criteria outlined in the WG charter (this is mostly a decision for the chairs, but we welcome feedback!)

Checking the RAW charter:
"RAW is not chartered to work on a solution. If solution work is needed, the Working Group will coordinate with the IESG to determine where the work will be done. If RAW is chosen for the solution work, the Working Group will recharter."

The intended status of the draft is Standards Track. It includes conformance language, e.g.,:
" The ping packets must be labeled in the same way as the data packets of the flow to monitor."
" These metrics should be collected:"

To me, the draft seems to be solution, hence, outside of the current RAW charter.

Thinking then on:
1) Is the RAW working group the correct WG for this work?
Also in the RAW charter:
" RAW extends the DetNet Working Group concepts"
As I understand, RAW OAM should be an extension of DetNet OAM, not RAW OAM on its own. The draft does not mention or refer to DetNet OAM. Well, DetNet OAM has not been finished yet, but there are drafts for it:
https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/
https://datatracker.ietf.org/doc/draft-mirsky-detnet-ip-oam/
Perhaps the OAM work could be done in the DetNet WG. DetNet OAM could be extended for wireless in the DetNet WG. 

So, I do not support the adoption of this draft.

Regards,
Janos

-----Original Message-----
From: RAW <[email-masked]> On Behalf Of Rick Taylor
Sent: Monday, March 30, 2020 12:14 PM
To: [email-masked]
Subject: [Raw] Call for adoption of draft-theoleyre-raw-oam-support-01

Hi All,

Cheers,

Rick and Eve
Co-chairs

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 31 Mar 2020 19:41:40 -0700

Hi Rick, Eve, et al.,
I've volunteered to review this draft, and I'd like to use this thread to
share my comments with you. My answers to three questions set forth by WG
Chairs are in-lined below tagged GIM>>, following my comments.

I enjoined reading the document - it is very well written, with an in-depth
understanding of OAM and the specifics of the wireless media. There's no
priority order in a way I've listed them.

   - the draft, as I understand, intended to define the OAM framework in
   RAW, list requirements for OAM in RAW, identify the RAW-specific scenarios.
   The document is on the Standards track, but Informational might be better
   suited as protocols and mechanisms to address the requirements likely will
   be specified in separate drafts.
   - Abstract may benefit from some update to closer align with the goal of
   the document explained in the Introduction section (I've applied minor
   editorial changes to the second from the end paragraph):

NEW TEXT:
   This document lists the requirements of
   the Operation, Administration, and Maintenance (OAM) features
recommended to construct a predictable communication
   infrastructure on top of a collection of wireless segments.  This
   document describes the benefits, problems, and trade-offs for using
   OAM in wireless networks to achieve Service Level Objectives.

   - I suggest using Service Level Objectives rather than Service Level
   Agreement. These are similar, but SLA exists in the form of a document,
   likely legal document between a Subscriber and an Operator. SLO, on the
   other hand, reflects what an Operator plans to achieve for the particular
   class of services.
   - several notes on the Terminology:
      - I would propose to change from "flow to be controlled" to "flow to
      be monitored"
      - OAM end-device is a useful term, but I didn't find it being used in
      the text. Instead, "maintenance endpoint" used in Section 5. I am used to
      MEP and MIP (used in Section 3.2) terminology, but that will require the
      definition of the Maintenence Domain. Alternatively, we can use
Test Point
      for MEPs and Monitoring Point for MIPs.
      - I think that the explanation provided for "defect" is closer to
      "quality degradation". A defect is usually is associated with a
state that
      has entry and exit criteria.
   - Section 2 is very useful; thank you. Do you think that changing the
   title to "Role of OAM in RAW" be helpful?
   - You may consider generalizing the second paragraph and refer to an
   orchestrator or SDN controller rather than to single out the PCE solution.
   - I'm not sure I fully agree with the following statement

OAM is in charge of controlling the replication/elimination processes.

I think that for the given RAW flow, PREOF on a node is controlled by the
central controller. OAM may be used to verify that PREOF is operating
properly on a node and within the domain.

   - The title of Section 3.1 gives me the opportunity to get on one of my
   favorite "OAM soap-box". There's a fine distinction between Continuity
   check and Connectivity verification. The former only concerns with the
   existence of a way to deliver a packet from node A to node B. The latter
   adds another condition - the absence of misconnection, i.e., no packets
   from nodes other than A, received on node B's interface. Of course, that is
   important if we consider the p2p connection-oriented communication model.
   - Multipath is undoubtedly an appropriate term to characterize a network
   that has more than one path between two nodes. An alternative might be the
   "meshed network".
   - Very interesting and appropriate discussion of a sufficient amount of
   OAM information in Section 3.3. It might deserve to be in the separate
   section and be expanded to how active OAM and on-path OAM (for example,
   iOAM, iPath, INT from P4) can be combined, complement each other.
   - you may find some OAM requirements in the expired document on OAM in
   overlay networks
   <https://www.ietf.org/archive/id/draft-ooamdt-rtgwg-ooam-requirement-02.txt>
   .

1) Is the RAW working group the correct WG for this work?
GIM>> I think yes
2) Are you as a WG participant ready and willing to review and raise
comments on the draft, if it is adopted?
GIM>> I do (for better for worse, for richer for poorer)
3) Does the draft meet the criteria outlined in the WG charter (this is
mostly a decision for the chairs, but we welcome feedback!)
GIM>> As I understand the stated scope of the draft "yes".

I have three questions I usually answer to myself when evaluating a
candidate document for WG adoption:

   1. Is the document reasonably well-written? Is it readable? - Yes
   2. Does the document address the real problem? - Yes
   3. Is the proposed solution to the problem plausible? - This document
   correctly identifies the problem and is very much needed to document the
   requirements to OAM in RAW.

Regards,
Greg

On Mon, Mar 30, 2020 at 3:13 AM Rick Taylor <[email-masked]>
wrote:

> Hi All,
>
> The authors of: draft-theoleyre-raw-oam-support-01 (have asked for a call
> for working group adoption of their draft.
>
> https://datatracker.ietf.org/doc/draft-theoleyre-raw-oam-support/
>