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

[Fabrice Theoleyre <[e-mail]>]

Dear Rex,

Thank you for your feedback. 

> 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?

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. 


> 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.

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

> 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.

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. 

> 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.

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?

> 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.)

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/ 

> 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
> 
> -- 
> RAW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw