Subject: [OPSAWG] definitions of continuity and connectivity

From: Thomas Narten <[email-masked]>
Date: Thu, 24 May 2012 12:13:32 -0400

Hi.

In developing requirements for TRILL OAM (e.g.,
draft-tissa-trill-oam-req-01.txt), we've had some difficulty finding
standard/crisp definitions of some well known terms. Specifically:

  Reachability: [is there an existing definition we can use?]

  Continuity: [is there an existing definition we can use?]

  Liveness: [is there an existing definition we can use?]

I would have expected to be able to reuse existing definitions of such
terms, but have not been successful.

draft-ietf-opsawg-oam-overview-06.txt says (in 2.2.5)

> 2.2.5. Connectivity Verification and Continuity Checks
> 
>    Two distinct classes of failure management functions are used in OAM
>    protocols, connectivity verification and continuity checks. The
>    distinction between these terms is defined in [MPLS-TP OAM], and is
>    used similarly in this document.

But, the MPLS-TP OAM document (RFC 5860 " Requirements for Operations,
Administration, and Maintenance (OAM) in MPLS Transport Networks") has
no such definitions. Indeed, the defintions and usages seem to be a
bit circular. E.g.:

> 2.2.2.  Continuity Checks
> 
>    The MPLS-TP OAM toolset MUST provide a function to enable an End
>    Point to monitor the liveness of a PW, LSP, or Section.

And that is pretty much all it says. Morever the term "liveness" is
not defined in RFC 5860 (or draft-ietf-opsawg-oam-overview-06.txt)

RFC 5860 also says:

> 2.2.3.  Connectivity Verifications
> 
>    The MPLS-TP OAM toolset MUST provide a function to enable an End
>    Point to determine whether or not it is connected to specific End
>    Point(s) by means of the expected PW, LSP, or Section.

But also does not define what connectivity means.

Are there standard definitions for the terms "continuity",
"connectivity" and "liveness"?

Thomas

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 24 May 2012 16:43:17 +0000

Thomas, 

IEEE802.1Q - 2011 has this definition:

"3.37 Connectivity Fault Management (CFM): Connectivity Fault Management comprises capabilities for detecting, verifying, and isolating connectivity failures in Virtual Bridged Local Area Networks."

If you really want to define "connectivity", you can use the description by Merriam Webster Dictionary: 
	the quality, state, or capability of being connective or connected <connectivity of a surface>; especially : the ability to connect to or communicate with another computer or computer system

For " Continuity check", IEEE802.1Q has this definition: 

"3.38 Continuity Check Message (CCM): A multicast CFM PDU transmitted periodically by a MEP in order to ensure continuity over the MA to which the transmitting MEP belongs. No reply is sent by any MP in response to receiving a CCM."

Linda 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Thomas Narten
> Sent: Thursday, May 24, 2012 11:14 AM
> To: [email-masked]
> Subject: [OPSAWG] definitions of continuity and connectivity
> 
> Hi.
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Thomas Narten <[email-masked]>
Date: Thu, 24 May 2012 15:55:53 -0400

> "3.37 Connectivity Fault Management (CFM): Connectivity Fault
>  Management comprises capabilities for detecting, verifying, and
>  isolating connectivity failures in Virtual Bridged Local Area
>  Networks."

> If you really want to define "connectivity", you can use the
> 	description by Merriam Webster Dictionary: the quality, state,
> 	or capability of being connective or connected <connectivity
> 	of a surface>; especially : the ability to connect to or
> 	communicate with another computer or computer system

I want a definition that makes sense for networking, and TRILL in
particular.

Does saying A & B are "connected" mean the same thing as B is
reachable from A? That if A sends a packet to B, there is a working
path?

And does it mean there is a two-way path between A&B, or just that a
one-way path exists and works?

> "3.38 Continuity Check Message (CCM): A multicast CFM PDU
>   transmitted periodically by a MEP in order to ensure continuity
>   over the MA to which the transmitting MEP belongs. No reply is
>   sent by any MP in response to receiving a CCM."

That is a circular definition... What does continuity mean?

How does continuity differ from connectivity (if the above definition
is correct)?

Thomas

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 May 2012 12:01:58 -0800

On 5/24/12 11:55 AM, Thomas Narten wrote:
> Does saying A&  B are "connected" mean the same thing as B is

I've tended to use "reachable" and "reachability" quite a bit
in the past (related to NAT traversal) and I would distinguish
between "reachable" and "connected."  "Connected" implies state
of some sort, even if it's just an open socket on an endpoint.
"Connected" would seem to suggest "reachable" but I don't think
it always does - you can have connection state maintained
while reachability disappears out from underneath.

> one-way path exists and works?

Because of the NAT stuff I tend to feel pretty strongly that it's
one-way.  I think that much of this stuff is impossible to separate
from routing.

Melinda

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 24 May 2012 20:38:26 +0000

IEEE802.1Q uses the wording "Continuity Check Message"  (instead of connectivity) because "connectivity" has the connotation as a line between two points. 

In IEEE802.1Q, the word  "Continuity" doesn't mean much other than in the phrase " Continuity Check Message". If you don't like the circular definition, you can simply apply the definition to "CCM". The important part is the "multicast" message to reach all the nodes in the VLAN. 

TRILL is multi-point to multi-point interconnect, the "connectivity" is not only between two points (same as in IEEE802.1Q). 
So it is not about A reaching B, it is about A reaching all the TRILL edge nodes which has the VLAN enabled. 

Linda 

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Thursday, May 24, 2012 2:56 PM
> To: Linda Dunbar
> Cc: [email-masked]
> Subject: Re: [OPSAWG] definitions of continuity and connectivity
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 25 May 2012 06:20:17 -0400

Some more background.

In defining terms like continuity/connectivity, I'm looking for a
definition that isn't operational.  When we give a definition in terms
of packets and responses to packets, that is like having C code be the
definition of something. We shouldn't need a detailed algorithm to
define terms.

What is driving this discussion is that the TRILL OAM document
(draft-tissa-trill-oam-req-01.txt) says things like :

> 4.2.1. Unicast
> 
>    OAM MUST have the ability to verify connectivity from an RBridge RB1
>    to a specific RBridge RB2.

and

>    4.3. Continuity Check
> 
>    [RFC5860] defines Continuity Check as the ability of end points to
>    monitor liveliness of a path or a section of a path [RFC5860]. We
>    use similar semantics in this document where end points are the
>    ingress or egress RBridges.
> 
>    OAM MUST provide functions that allow an RBridge to perform a
>    Continuity Check to any other RBridge.

I have a very practical question. Are the two MUST requirements above
the same, or are they different? I can't tell without knowing what the
difference between continuity and connectivity is. 

Thomas

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 25 May 2012 03:57:28 -0700 (PDT)

Hi,

The only glossary that I know of that contains both terms is at ATIS.
   http://www.atis.org/glossary/

In my opinion, a continuity check is the same as verifying connectivity.

Hope this helps,
Chris

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 25 May 2012 14:43:22 +0000

"Continuity Check" should be the periodic OAM messages in fixed intervals (e.g. 3ms) which are used to verify the connectivity between end points. 

So "Continuity" itself is not same as "connectivity". 

Connectivity is declared as "down" when an end point not receiving "Continuity Check" messages for X number of intervals. 

Linda 

> Sent: Friday, May 25, 2012 5:20 AM
> To: [email-masked]

---

From: t.petch <[email-masked]>
Date: Thu, 31 May 2012 18:04:08 +0100

----- Original Message -----
From: "Thomas Narten" <[email-masked]>
To: <[email-masked]>
Sent: Friday, May 25, 2012 11:20 AM

> difference between continuity and connectivity is.

Different.

This was hammered out in MPLS but RFC5860 is sloppy in this regard.

Continuity Check is proactive, at a rate commensurate with the time
within which failures should be detected, which could be mS or could be
seconds.  Thus it must be low cost, simple, basic.

Connectivity Verification is on demand, run when it is needed, perhaps
as a result of an alarm; it may not be run for months, so can afford to
be heavyweight, gathering everything that might be needed.

In a sense, both are solutions, not requirements.  RFC5951 talks of on
demand and proactive modes, which I think better.

I think that the authors of draft-tissa-trill have rather missed the
point, and need to read their Normative References more carefully.

And their I-D will be easier to read once the author list on the front
page is cut down to size, as it must before it ever makes it to RFC.

Tom Petch

---

From: Thomas Narten <[email-masked]>
Date: Thu, 31 May 2012 15:37:53 -0400

Hi Tom.

> seconds.  Thus it must be low cost, simple, basic.

Does this also imply multiple messages sent, and getting a percentage
of packets lost? As opposed to a single request/response?

> be heavyweight, gathering everything that might be needed.

Does this also imply a single message/response transaction? Or can
this also imply something more sophisticated, involving multiple
messages?

What I'm trying to do is separate what "continuity" and "connectivity"
are intended to achieve, vs. mechanics for acheiving the desired
semantics. But a lot of the discussion about the terms seems to be
implying a solution rather than what the solution is required to
achieve.

And while I understand that on-demand vs. proactive is an important
distinction for when/how to invoke functionality, I'd like to
understand the distinction between the two in terms of what they are
supposed to achieve (independently of whether invoked proactively or
on-demand).

Thomas