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

[Rex Buddenberg <[e-mail]>]

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:
> I support the adoption. The draft already has a very good structure
> and content.
> 
> > 
> > -----Original Message-----
> > From: RAW <[e-mail]> On Behalf Of Rick Taylor
> > Sent: lundi 30 mars 2020 12:14
> > To: [e-mail]
> > Subject: [Raw] Call for adoption of draft-theoleyre-raw-oam-
> > support-01
> > 
> > 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-th
> > eoleyre-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
> > 
> > --
> > RAW mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/raw