Re: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt

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

Hello again and again Don

Based on the positive return from ROLL, I applied your proposal to use the term "Lane".

I pushed draft 11 to get a status of where we are with our discussion.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-raw-architecture/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-raw-architecture-11.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-raw-architecture-11

all the  best;

Pascal


> -----Original Message-----
> From: RAW <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
> Sent: mardi 6 décembre 2022 12:44
> To: Don Fedyk <[e-mail]>; [e-mail]
> Cc: [e-mail]; DetNet Chairs <[e-mail]>
> Subject: Re: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt
> 
> Hello again Don
> 
> The proposed changes are visible in https://github.com/raw-wg/raw-
> architecture/commit/ad9525dd399cfe11da645ccc591272cc2b97d75e
> 
> Major:
> 
> - Added at beginning of terminology:
> "
>                                                RAW inherits and
> augments
>     the IETF art of Protection as seen in DetNet and Traffic
> Engineering.
> "
> 
> - New Figure of a Track
> - Definition of East, West, North, and South
> - Definition of Lane
> 
> In parallel I'm moving the ROLL draft to use lane as well. Waiting for
> WG approval (or lack of disapproval) to publish.
> 
> All the best
> 
> Pascal
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Pascal Thubert (pthubert)
> > Sent: mardi 6 décembre 2022 9:25
> > To: Don Fedyk <[e-mail]>; [e-mail]
> > Cc: [e-mail]; DetNet Chairs <[e-mail]>
> > Subject: RE: [Raw] FW: I-D Action: draft-ietf-raw-architecture-10.txt
> >
> > Hello Don
> >
> > > >I'm good with "protection" and I agree with the history you point
> > out.
> > > >The way we use the Track appears consistent with that term to me
> > too.
> > >
> > > My point was "Track" is new to me - not been following Roll perhaps
> > my
> > > bad but what I offered to do was define Track without using the
> term
> > > and see if the WG agreed Track was what to call it.
> >
> > "Deterministic" Wireless has been an IETF topic for 10 years now. And
> > Track is the term that was used all that time, see RFC 9030. There
> are
> > a number of 6TiSCH people at RAW, including draft authors.
> >
> > Think about the gnu track analogy: all the gnus follow the track but
> > you do not know in advance where a particular gnu will leave the
> marks
> > of its hooves. Once the herd has passed, one can see from above the
> > track where the herd was, and observe the density of the marks on the
> > ground. Similarly, when you do something like overhearing, the packet
> > may be relayed by a node that is not the most intended next hop, so
> > you do not really know where a packet passes until it did it. What we
> > call a path is that observed experience after the fact, while the
> > track is the a priori knowledge of the overall area where all the
> > marks will be for the whole herd, the gnus ancestral knowledge if you
> like.
> >
> > > I caught my self saying "protection path" then realized when
> talking
> > > with Lou that "Protection" embodies the whole concept.
> > > >
> >
> > Happy to use that term
> >
> > > >I'm not good with "RAW" since though RAW is using the concept, it
> > did
> > > >not create it and is not the end of it.
> > >
> > > I only used the term to mean the RAW flavor of protection.
> > > I'm fine dropping that.
> >
> > Cool
> >
> > > >We cannot ignore how much work has taken place at ROLL and 6TiSCH,
> > > >which contribute to the work on reliable and available Wireless by
> > > >providing the route installation and the forwarding over TSCH,
> > > >respectively.
> > > >
> > > >Just look at
> > > >https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-
> > projection.
> > > >I cannot easily go and tell ROLL that the term they have been
> using
> > > >forever must now change because of RAW. And This draft is the only
> > > >way I'm aware of to build the Tracks in a centralized fashion -
> > > >unless we argue that PCEP is a valid contender in a wireless mesh?
> > >
> > > Well, it points to RAW as the defining place for Track yes I see.
> >
> > ROLL did not publish an architecture but ROLL and RAW do. Conversely,
> > RAW and ROLL (mostly) do not define standards, 6TiSCH only designed
> > the missing pieces that did not have a home, but for the most part,
> > worked with other groups (to the point of helping start some). So
> far,
> > ROLL has provided routing solutions for 6TiSCH and then RAW. Keeping
> > those groups in tight sync is useful and necessary. This is not an
> > IETF process, this is us. It is a mark of respect from RAW that we do
> > not change the words that ROLL has been using to work with and for
> us.
> >
> >
> > >
> > > >
> > > >I suggest we settle for "Protection Track".
> > >
> > > Again, not my decision but the WGs. Perhaps
> > > - Protection as the superset
> > > - Protection Track is then the active set of paths in that
> > >   protection scheme?
> > > - And Protection Tracks are the active set of paths for
> > >   separate services?
> > >
> > > Googling images of track I realize that I like "lanes".
> > > Protection lanes?  Was lanes considered? Lanes are a subset of
> track.
> >
> > ROLL has the term leg, though it is never used in conversation (as
> > opposed to Track), and does not come from 6TiSCH but from the need to
> > construct east west protection paths. I agree that lane is better.
> I'm
> > OK to ask ROLL to change. Can you please look at the definition
> there:
> >
> > From https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-
> > 29.html
> > "
> > 2.4.5.7. Leg
> >
> > An end-to-end East-West serial path. A leg can be a Serial Track by
> > itself or a subTrack of a complex Track with the same Ingress and
> > Egress Nodes. With this specification, a Leg is installed by the Root
> > of the main DODAG using a Non-Storing Mode P-DAO message, and it is
> > expressed as a loose sequence of nodes that are joined by Track
> > Segments.
> >
> > As the Non-Storing Mode Via Information option (NSM-VIO) can only
> > signal sequences of nodes, it takes one Non-Storing Mode P-DAO
> message
> > per Leg to signal the structure of a complex Track.
> > Each NSM-VIO for the same TrackId but with a different Segment ID
> > signals a different leg that the Track Ingress adds to the topology.
> > "
> >
> > Also happy to import the resulting definition of "lane" in this
> > architecture and refer from the ROLL document like we do for Track
> for
> > consistency.
> > I sent a separate email on that to RAW 'n' ROLL.
> >
> > > >
> > > >
> > > >> Remove Network Plane - It is a Data plane or a control plane.
> > > >> Rational Network plane is not a common term.
> > > >>
> > > >
> > > >See section   "4.4.3.  The Network Plane" of RFC 8655
> > >
> > > I see it is a composite plane and still _rarely_ referenced in
> > DetNet.
> > > I'm familiar with data plane, control plane, management plane and
> > > Network.  So OK my bad.  If the WG thinks it brings clarity then it
> > is
> > > an established term.
> > >
> > >
> > > >> Remove OODA. - Rational the OODA loop is one type of feedback
> > > >> loop common in cybersecurity.  In RAW there are multiple
> feedback
> > loops.
> > > >
> > > >It's a very abstract model and that's the only one we have defined
> > > >a mapping for. It fits very well the detnet network plane roles of
> > PCE,
> > > >PSE, OAM and PAREO, respectively.
> > > >Do you have something in mind that does not match that model?
> > > >Should
> > > we
> > > >describe it in the architecture?
> > >
> > > It is the "orient" part I think is being forced.
> > > OODA looks to me like a larger system of multiple feedbacks.
> > > It is a general system and can be fitted to many situations.
> >
> > It's a critical piece actually. Probably the hardest to do right.
> > "orient" turns the history into prediction and prediction into
> > recommendation (this link will fail occasionally, and here's the
> > response to this situation). That's the process by which all the
> > statistics/ML activities (e.g., about link reliability and
> > availability) at the PCE are transformed into actionable
> > rules/policies in the PSE (which is deterministic not statistical).
> >
> >
> > >
> > > There are multiple feedback loops.
> > >
> > > In control loops you have a system with an operating goal, a
> > > measurement function and feedback to maintain the goal.
> > > There is no orienting measurement is implicit in the feedback loop
> > > design.  Since we deal with packets and paths we have discrete
> steps
> > > thresholds and actions.
> >
> > It is always there and it's typically called a PLC. The transforms
> the
> > measurement into a decision action. "Orient" is the intelligence in
> > that process; even if it is a plain mechanism, some intelligence
> > designed that mechanism and that's the orient piece. See it as a
> > transducer between sensing and actuating. In the example you give the
> > PLC activity is not visible on the wire, only the resulting action
> > decision is; with RAW, the PLC is split between PCE and PSE, and
> there
> > will be a time where the "orientation" will be signaled.
> >
> > >
> > > There is also in theory a network manager role that tries to
> > > optimize over all service - maximizing network utility however when
> > > services are equal priority established services win over not yet
> > > established services. When priority is involved higher priority
> services win.
> > > I  contend this higher level does not exist and you either have
> > > equal services FIFO or priority services or both.
> >
> > And the netAdmin (via NME) does the "orient" part by providing the
> > policy to tag flows and the QoS engine does the "action" part.
> >
> > > Again, a question for WG. Does OODA bring clarity over a simple
> > feedback?
> >
> > Waiting on a response.
> >
> > Note that the OODA loop was discussed many times at the RAW WG. The
> > term has been there since the first publication as a WG document (01,
> > since 00 is a republish of the personal submission as is). It was in
> > every architecture presentation at least since IETF 111, see for
> > instance the slide 1 (#2) of
> > https://datatracker.ietf.org/meeting/111/materials/slides-111-raw-
> > draft-ietf-raw-architecture-01
> >
> >
> > The actions I agreed upon and saw no objection:
> > - use the term "protection"
> > - define lane in the RAW architecture and rename ROLL's leg to lane,
> > provided ROLL does not oppose. The lanes are individual east west
> > paths. Note: A protection path may use several lanes and join them
> (so
> > a car can move from a lane to the other) using PAREO capabilities.
> >
> > Please let me know you still see a need for more changes;
> >
> > All the best,
> >
> > Pascal
> >
> >
> > >
> > >
> > > >
> > > >
> > > >>
> > > >> Details:
> > > >> Reading over the RAW architecture I would remove Track and refer
> > to
> > > >> places where Track is used as as RAW protection and active RAW
> > > >> protection paths
> > > >> - This reuses IETF terminology.
> > > >> RFC 9030 defined a Track but it is not common use outside that
> > > group.
> > > >
> > > >It is used in the IETF wireless / IoT groups in INT area and RTG
> > Area.
> > > >
> > > >
> > > >> The WG should then decide if a single term such is Track (or
> > other)
> > > >> can be used.  My issue with the term Track is it is singular in
> > > >> nature and the usage here varies from singular to multiple.
> > > >
> > > >Agreed
> > > >
> > > >
> > > >> There are two fundamental concepts:
> > > >> a protection set and
> > > >> the active protection set.
> > > >
> > > >True. I figured from the discussion with Lou that the "active
> > > >protection set" is a TE path, so I changed the terminology to that
> > in
> > > >the latest publication. Was that wrong? Note that as I insisted at
> > > >the WG meeting in London, the 2 sets are not of the same nature.
> > > >The
> > > former
> > > >is a potential, the latter is an actual. Using "protection set"
> > > >for both hides that subtlety under the carpet.
> > >
> > > I agree.
> > > >
> > > >
> > > >> Currently, the RAW Architecture talks about a Network plane.
> > > >> I think it means a data plane.  Network plane is not widely
> used.
> > > >>
> > > >> I would remove OODA loop.   There is not much reference to
> > > >> it in the IETF and I think it is more a security feedback loop
> > than
> > > a
> > > >> run time operational feedback loop. We have feedback loops. I
> > think
> > > >> the PAREO loop stays largely as as you have defined it.
> > > >
> > > >We do not have a PAREO loop. PAREO is the action in OODA.
> > >
> > > Yes I agree I used the wrong wording for PAREO.
> > > >
> > > >> RAW (and other networks) have multiple feedback loops.
> > > >> Link state with statistics (comprises a topology feedback loop).
> > > >> RAW active protection path set and service statistics is another
> > > feedback
> > > >> loop.
> > > >
> > > >I'm not aware of feedback loop in the data plane though. The
> > > >closest I'm aware of would be FRR/LFA but that's not really a
> > > >control loop, more a reflex action to avoid a broken path.A
> > >
> > > The feedback loop for QoS is RFC2386. Generally considered not a
> > > good idea. This is why I questioned the use of PAREO actions and
> why
> > > I suggest they should be limited.
> > >
> > > >
> > > >> Currently the architecture allows RAW to ask for a path to be
> > > >> computed (one or several protection paths).
> > > >> Then RAW uses local decisions locally decide if it needs to
> > > >> refine the active path out of the set.  To maintain stability
> > > >> over all paths, path allocations of capacity should be sized to
> > > >> the fullest use of the protection path set assigned although
> > > >> locally RAW can decide not to use all paths.
> > > >
> > > >True. Do we need more words in the document on that?
> > >
> > > I think so to alleviate the instability concerns.
> > > >
> > > >> I think for path computation RAW should assume it uses all
> > resource
> > > >> allocated in "active RAW protection". When less resources are
> > > >> used over time
> > > >> - then it should relinquish the resources.
> > > >> This slow adjustment of the actual usage is another feedback
> loop.
> > > >>
> > > >> Here is what I think this looks like.
> > > >>
> > > >>                    +--------------+
> > > >>         +--------->+ Compute RAW  +-----------+
> > > >>         |          | Protection   |           |
> > > >>         |          | Paths        |           |
> > > >>         |          +--------+-----+           |
> > > >>         |                   ^                 |
> > > >>         |                   | Network         V
> > > >>  +------+---------+         | Link      +-----+-----+
> > > >>  |Request RAW     |         | State     |           |
> > > >>  |Service  Path   |         +-----------+Deploy and |
> > > >>  |                |                     |Monitor    |
> > > >>  |Traffic Request |         +-----------+RAW        |
> > > >>  |[Add or delete  |         | Service   |protection |
> > > >>  | Resources]     |         V State     |           |
> > > >>  +------+---------+   +-----+-------+   +-----+-----+
> > > >>         ^             |RAW actions  |         ^
> > > >>         |             |PAREO        +---------+
> > > >>         |             +-----+-------+  Local
> > > >>         |                   |          Change
> > > >>         |     Service       |
> > > >>         |     Change        |
> > > >>         +-------------------+
> > > >
> > > >I like this drawing, many thanks. The "Network Link State"
> > > >is not really correct though. More like "Network Link Stats", one
> > > >letter, very different meaning. Or both if we consider a permanent
> > > stat
> > > >of 0 to be a link down information.
> > >
> > > Yes full link capacity to degraded to zero. I think you have better
> > > wording.
> > >
> > > >
> > > >Just like there's async and periodic OAM-based "state"
> > > >information on links (passing, not passing, assumed reliability /
> > > >PDR) to the PSE, there must be periodic and async stats to the
> PCE.
> > > >When
> > > the
> > > >stats differ to widely from those used to compute the Track, the
> > > >PCE may update or rebuild the protection Track. OTOH, if the stats
> > remain
> > > >in an acceptable range, the PCE will rely on the PSE to adapt and
> > > >refrain from impacting the Track.
> > > >
> > > >This is the big difference between what the PSE and the PCE see.
> > > >The PSE sees links as usable or not at one instant. The PCE sees
> > > >quality stats over long periods. As opposed to classical IGPs the
> > > >model in radio networks has to accommodate link flapping smoothly.
> > > >E.g., RPL is built for that, that's why it builds DODAGs as
> opposed to trees.
> > > >
> > > >> There are three possibilities:
> > > >> - The quality is poor, and more resources need to be
> > > >>   requested.  If a RAW service determines that the service
> > > >>   is not getting sufficient packets through it should ask
> > > >>   for a better RAW protection (set of paths) .
> > > >>
> > > >> -The quality meets it targets and allocation of resources  stays
> > > >> constant.
> > > >>
> > > >> - The quality meets it target but the connection is
> > > >>   consuming excessive bandwidth/capacity.  Currently RAW
> > > >>   makes this determination locally.  I think that RAW
> > > >>   should release resources within
> > > >>   some bounds.
> > > >>
> > > >> This scheme should be set up to reduce the chance that RAW
> > services
> > > >> will compete by over allocating (blocking) or under allocating
> > > >> (congesting).
> > > >
> > > >
> > > >True. Then again as a DetNet Extension, RAW uses provisioned
> > > >resources so on paper congesting is not part of the game. On
> paper,
> > > >there should be enough resources for all RAW flows using all the
> > > >PCE allocated resources. The game is to save
> > > >1) energy and 2) spectrum which can then be used by non-
> > deterministic
> > > >flows.
> > >
> > > >
> > > >Arguably, the link rate may vary (with MCF). OAM must capture
> that,
> > > and
> > > >the PSE of some flows will have to react and stop using that link,
> > > >while for other flows the link will remain usable. Maybe a
> sentence
> > > >or
> > > >2 to clarify that is in order?
> > >
> > > Yes, Even if you over allocate bandwidth there are cases where a
> > > loss will cause congestion. You can argue for queuing that
> > > sacrifices
> > other
> > > flows before RAW flows but ultimately you may not be satisfying.
> > > Some environments/wireless links may be bandwidth starved.
> > > >
> > > >All the best,
> > > >
> > > >Pascal
> > >
> > > And I apologize for not having given input earlier.
> > >
> > > Cheers
> > > Don
> > > >
> > > >
> 
> --
> RAW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw