Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-07.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello again Greg

> It might be that here we talk about the reliability. I see the availability as reflection of the reliability of the path over a period of time. In fact, media with the constant bit-rate, e.g., SONET/SDH, had availability defined and measured for decades. I’ve attempted to extend that model into a packet networks in draft-mirsky-ippm-epm<https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/>.

True, fixed.

> Is it that the affected process is not the transmission, i.e., the process of transmitting, but the reception of a packet?

I’d agree if transmitting == sending or emitting; which is often the way we (ab)use the word. Here it is understood as the act of passing from one to another.

> Not sure if 5G URLLC is a distinct technology different from, for example, massive Machine Type Communication (mMTC) using 5G

Arguably it’s all OFDMA but we want to focus on URLLC as it is the angle that seems to echo the DetNet requirements.


“

[BFD] detect faults in the path between an Ingress and an Egress

      forwarding engines, but is unaware of the complexity of a path

      with replication, and expects bidirectionality.  BFD considers

      delivery as success whereas with RAW the bounded latency can be as

      important as the delivery itself.


“


> Not necessarily. It appears that BFD Demand mode with unsolicited notifications may be more suitable then the Asynchronous BFD mode. The use of the Demand mode in MPLS is analyzed in draft-mirsky-bfd-demand<https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/>. It is possible to extend the scope the draft to an IP network.

The bottom line is that link up down is not key. The key is bounded latency. I changed the text to:
“
   *  [BFD] detect faults in the path between an Ingress and an Egress
      forwarding engines, but is unaware of the complexity of a path
      with replication, and expects bidirectionality.  BFD asynchronous
      mode considers delivery as success whereas with DetNet and RAW,
      the bounded latency can be as important as the delivery itself,
      and delivering too late is actually a failure.  BFD Demand mode
      with unsolicited notifications may be more suitable then the
      Asynchronous BFD mode.  The use of the Demand mode in MPLS is
      analyzed in [I-D.mirsky-bfd-mpls-demand] and similar
      considerations could apply to IP as well.
“

I need to read your draft to understand more. What can we do to address bounded latency conformance?
This was the point above, and it’s a MAC issue so pure PHY-based demand BFD cannot tell.

> The Error Performance Measurement<https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/> draft, referenced earlier, uses PM and FM OAM mechanisms to determine availability/unavailability of a path according to predefined SLA.

I added that information in the “DetNet OAM” section.

“



   The RAW OAM operation in the Network Plane observes either a full
   Track or subTracks that are being used at this time.

“
> Would there be a value in also monitoring available but not currently used subTracks using active OAM methods? It seems that information about unused links could be used by PSE in making packet forwarding decision.

Certainly! Service-Layer Assurance should be able to test each individual PREOF operation (in vs out). This might mean injecting a packet in the middle of the Track and extracting it a few hops later.

Replaced with

   RAW In-situ OAM operation in the Network Plane may observe either a
   full Track or subTracks that are being used at this time.  Additional
   out-of-band RAW OAM may observe all including unused segments to
   prepare for a rerouting decision.  Finally, the RAW Service Layer
   Assurance may observe the individual PAREO operation of a relay node
   to ensure that it is conforming; this might require injecting an OAM
   packet at an upstream point inside the Track and extracting that
   packet at another point downstream before it reaches the egress.

“

                                                     Within that

   framework, OAM messages follow the same forward path as the data

   packets and gather information about their individual treatment at

   each hop.  When the destination receives an OAM message, it gets a

   view on the full path or at least of a segment of the path from the

   source of the flow.



   In-situ OAM (IOAM) adds telemetry information about the experience of
   one packet within the packet itself [I-D.ietf-ippm-ioam-data],


“

> Note that such HbH mode is costly on transit nodes. It can be expected that e2e OAM that monitors the entire path from ingress to egress would be broadly used.

May be different for RAW. Here we need to switch between subTracks.

> HbH telemetry could be used, for example, to optimize subTrack. If the task is to monitor a particular subTrack, then e2e PM and FM OAM could be what an operator needs.

You lost me. I thought you were advocating for e2e. Please let me know if you need more text than the one I already added (see diffs)

> IOAM and analogous on-path telemetry methods are capable of facilitating collection of useful telemetry information that characterizes the state of a system as experienced by the packet. But because of statistical character of a packet network, these methods may not be used to monitor the continuity of a path (Track) or proper connectivity of the Track (no leaking packets across Tracks).

If you do not mind I’ll add that quote to the text.

“



   Classical OAM typically measures information at the transmitter,
   e.g., residence time in the node or transmit queue size.

“

> A residence time (RT) can be defined as time period between the reception of a packet starts and the transmission of the packet begins. If we use that, the RT is more useful for a transit node, not ingress or egress. Also, RT is for an ordered pair of ingress and egress interfaces of the given node. A special technique can be used in a path engineered environment where a test probe can be directed over an arbitrary path.

I added text including terminology based on the above. Many thanks! All this makes you  a contributor. I added your name if you do not mind?

“

   it is important that RAW OAM captures the state of the

   medium across an adjacency over multiple transmission and over a

   recent period of time, whether the transmitted packets belong to this

“
> That is a very important requirement for PM OAM in RAW (I think that the same should be true for DetNet too).

“

                                This makes an approach like HTS more

   suitable as it can trigger the capture of multiple information over

   a short period of time.  On the other hand, the PSE needs a

   continuous measurement stream where a single trigger is followed by a

   periodic follow up capture.

“
> If the goal is to allow PSE to evaluate the availability of a Track, then such function might be located at the egress of the Track (see the EPM draft). Then the function would notify forwarding controlling function of the PSE once conditions on the Track degraded below pre-defined threshold.

Yes, that is the intent when the PSE source routes the subTrack to be used.

“

   out-of-band OAM packets must circulate in the exact same
   fashion as the flows that they observe.

“
> Out-of-band packets can be used to collect measurement data, counters. SNMP query is one of examples. Out-of-band cannot be used for monitoring a data flow as packets outside the flow are scheduled, processed differently. Active OAM (per definition in RFC 7799) methods use specially constructed test packets. It is important, if not critical, that these test packets are in-band with the monitored data flow. Some environments, e.g., ECMP, present challenges to keeping test packets in-band with data packets.

Please see https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-04.html; the out of band OAm can be tagged just like the DetNet flows and be subject to the same forwarding plane behavior. RAW is actually a use case for that. And the expectation includes alerting if the bounded latency is not obtained. Since it is DetNet I had to use path instead of Track but we are talking about the same thing.

Do I miss something?

Again, many thanks!

I pushed 08 with this, please see https://www.ietf.org/rfcdiff?url2=draft-pthubert-raw-architecture-08.txt

You all keep safe,

Pascal



From: Pascal Thubert (pthubert)
Sent: jeudi 17 juin 2021 16:15
To: [e-mail]; pthubert=[e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Raw] New Version Notification for draft-pthubert-raw-architecture-07.txt

Hello Greg 😊

Many thanks for your great comments. Being inlined in a word document, they helps me a lot as author of the personal submission, but will not be seen by many people in the list and maybe lost in archival.
That’s a bit sad, there are many very interesting discussion topics in your comments. I’ll come back for discussion threads on individual topics. In the meantime I’m applying the most basic changes to the latest github version.

Again, many thanks!

Pascal

From: RAW <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: mercredi 16 juin 2021 21:39
To: pthubert=[e-mail]<mailto:pthubert=[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-07.txt


Hi Pascal,

apologies for a delay to respond. I've read the draft and believe it is a great document that is the absolute must for anyone who, as I am, is not intimately familiar with wireless media and the work on TISCH in the 6tisch WG. thank you for making to read it.

I've added several comments in the attached copy (along with some editorial knit picking). Please feel free to use the copy for the continued discussion or extract comments into an email.



Best regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


[cid:image001.gif@01D7684A.5CB5B5C0]
[cid:image002.gif@01D7684A.5CB5B5C0]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn/>
Original Mail
Sender: PascalThubert(pthubert)
To: Fabrice Theoleyre;
CC: [e-mail];[e-mail];gregory<mailto:[e-mail];[e-mail];gregory> mirsky10211915;Carlos J. Bernardos;[e-mail];
Date: 2021/06/07 08:27
Subject: Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-07.txt
Good point, Fabrice

I'll add text saying that ingress and egress serve as Maintenance Entity Group End Points.

Note that the role of ingress covers more stuff like track selection, encapsulation and PSE.

Keep safe!

Pascal

> -----Original Message-----
> From: Fabrice Theoleyre <[e-mail]<mailto:[e-mail]>>
> Sent: lundi 7 juin 2021 17:19
> To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
> Cc: Greg Mirsky <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Carlos J. Bernardos
> <[e-mail]<mailto:[e-mail]>>
> Subject: Re: New Version Notification for draft-pthubert-raw-architecture-
> 07.txt
>
> Hi Pascal,
>
> I just read your draft.
>
> For the ingress / egress end-systems in section 4.3, shouldn’t you use the
> term MEP?
> Besides, I have the feeling that MEP should be the hosts at the border of the
> wireless part: in that way, you focus uniquely on the wireless links to
> collect all the measurements, etc.
> It would be easier to manage.
>
> What’s your opinion?
>
> Fabrice
>
>
>
>
>
>
> > Le 4 juin 2021 à 15:49, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> a
> écrit :
> >
> > Many thanks for your comments Greg!
> >
> > I added subsections to section 4.3 of draft-pthubert-raw-architecture 07;
> can you please have a look?
> >
> > Coincidently the new text affects the (todo) section 4.3 of draft-ietf-raw-
> oam-support.
> >
> > Fabrice and all, it would be nice that we sync on this. We might also
> exchange pieces of text between the 2 drafts.
> >
> > Keep safe;
> >
> > Pascal
> >
> > -----Original Message-----
> > From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
> > Sent: vendredi 4 juin 2021 15:38
> > To: Georgios Z. Papadopoulos <[e-mail]<mailto:[e-mail]>>;
> Georgios Papadopoulos <[e-mail]<mailto:[e-mail]>>; Lou Berger
> <[e-mail]<mailto:[e-mail]>>; Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Rex
> Buddenberg <[e-mail]<mailto:[e-mail]>>
> > Subject: New Version Notification for draft-pthubert-raw-architecture-
> 07.txt
> >
> >
> > A new version of I-D, draft-pthubert-raw-architecture-07.txt
> > has been successfully submitted by Pascal Thubert and posted to the IETF
> repository.
> >
> > Name:        draft-pthubert-raw-architecture
> > Revision:    07
> > Title:        Reliable and Available Wireless Architecture/Framework
> > Document date:    2021-06-04
> > Group:        Individual Submission
> > Pages:        35
> > URL:            https://www.ietf.org/archive/id/draft-pthubert-raw-
> architecture-07.txt
> > Status:         https://datatracker.ietf.org/doc/draft-pthubert-raw-
> architecture/
> > Html:           https://www.ietf.org/archive/id/draft-pthubert-raw-
> architecture-07.html
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-raw-
> architecture
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-pthubert-raw-
> architecture-07
> >
> > Abstract:
> >   Reliable and Available Wireless (RAW) provides for high reliability
> >   and availability for IP connectivity over a wireless medium.  The
> >   wireless medium presents significant challenges to achieve
> >   deterministic properties such as low packet error rate, bounded
> >   consecutive losses, and bounded latency.  This document defines the
> >   RAW Architecture.  It builds on the DetNet Architecture and discusses
> >   specific challenges and technology considerations needed to deliver
> >   DetNet service utilizing scheduled wireless segments and other media,
> >   e.g., frequency/time-sharing physical media resources with stochastic
> >   traffic.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >

--
RAW mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/raw