Subject: Re: [Mpls-interop] Connectivity Verification and Cotinuity Check inMPLS-TP

From: "Italo Busi" <[email-masked]>
Date: Tue, 2 Sep 2008 16:03:31 +0200

Nurit,
 
if I understand well, you are asking which is the preferred alternative for
implementing CC&CV among the following three options:
 
1) define a new tool combining CC&CV
 
2) change the semantic of the BFD discriminators
 
3) define an optional global identifiers field within BFD
 
Is my understanding of the possible options correct?
 
Further questions in line marked with [ib]
 
Thanks, Italo

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Sunday, August 31, 2008 2:42 PM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: MEAD team; [email-masked]
Subject: Re: [Mpls-interop] Connectivity Verification and Cotinuity Check
inMPLS-TP

Hi,

I think that most of agree that there is no real distinction between CC and CV
and that we can combine both as CC & CV function. Note that in G.8113 they are
combined. 

In order to do it (and in any case for the CV function) we need to have a global
identifier that identifies uniquely the monitored path.

BFD could be use for the CC function. The BFD session identification (My
Discriminator / Your Discriminator) has a local scope by the two ends activating
the session: the same discriminator values may be used for a different path to
be monitored by a different couple of nodes in the same network.  When there are
other means to identify the path uniquely there is no need for the BFD session
identifiers. For example with VCCV-BFD the Discriminator fields are not used
because the PW label is sufficient to identify the BFD session. I think this is
not the case for LSP or TC. As the LSP label can be used from the interface
space (i.e. local to the interface) and in order to use it we need to understand
that the scope of the label is the interface and then use the interface ID and
the label ID as the identifier... 

[ib] I do not understand your argument here. An MPLS label (from whichever label
space) uniquely identifies the LSP or the PW. The label space impacts only the
way the label is looked up. When PHP is used, the LSP endpoint does not receive
any label that identifies the LSP and therefore must rely on the BFD session
identifiers. When PHP is not used, the LSP label is present and uniquely
identifies the LSP. In this case I think that the LSP label can be used to
identify the BFD session like in VCCV-BFD.
 
[ib] In both cases (PW and non PHP-ed LSP) you still need connection identifiers
with a global scope  in order to detect misconnections. When the MPLS label is
used to identify the LSP or the PW a CC&CV packet belongs to, these identifiers
can be checked against an expected value: in this way it is possible to detect
which LPS or PW is misconnected.

Since we want to have a similar operation for section, PW/TC-PW, and LSP/TC-LSP
and since that for the CV we need to rely on identifiers uniquely assigned to a
path, we need to define a mechanism to have a unique identifier for the BFD
session.

We could for example change the semantic of the BFD discriminators to have
global scope, but we need to evaluate the case of interoperability with MPLS
BFD, etc. 

We could also think of extending BFD and define an optional global identifiers
field.

And of course we can define a new tool for the CC & CV function.

Please advice which tools should be used for the combined CC&CV function and if
it is BFD how can we have the global identifiers.

Best regards,

Nurit

  _____  

From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) 
Sent: Monday, August 11, 2008 11:59
To: [email-masked]
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: Connectivity Verification and Cotinuity Check in MPLS-TP

Hi all,

In discussions between the authors of the OAM Analysis and OAM Framework
documents, the question was raised on the inherent differences between the CC
and CV operations and whether they are both relevant for differentiation between
on-demand and pro-active activation.  The basic difference between the two
operations is:

*         CC - checks the "continuity" of the path between two MEPs of an ME,
there are tools available that perform CC (e.g. BFD) using local identifiers for
the ME check and therefore may be subject for border-cases of inconsistency.

*         CV - checks "connectivity" between the two ends of the ME usually
based on global identifiers, and may also give path information, to verify that
all MIPs are reacting correctly.

It is unclear whether there is a need for "On-demand CC" and "Pro-active CV"
(and there are differences of opinion) or whether the two operations complement
each other in this characteristic.  We would like to receive some feedback from
the Service Providers on whether there is a need to separate these two
operations or whether it wouldn't be best to just talk of - "pro-active CC &CV"
as opposed to "on-demand CC & CV", i.e. combining the functionality under one
roof and just differentiating between the pro-active (or continual) CC & CV
operation, and the on-demand (in reaction to a pro-active fault, or during
network periodic checks) CC & CV?

Your comments and clarifications would be very much appreciated,

Best Regards,

Yaacov Weingarten

Nokia Siemens Networks GmbH & Co. KG

Industry Environment - CET

3 Hangar St Neve Ne'eman B

45241 Hod Hasharon, Israel

email:   <mailto:[email-masked]> [email-masked]

tel:     +972-9-775 1827

mob:   +972-54-220 0977

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Italo Busi" <[email-masked]>
Date: Tue, 2 Sep 2008 16:34:54 +0200

Nurit,
 
I fully agree with you: we cannot rely on the label to detect misconnections.
 
In order to detect the misconnection we still need a unique identifier with a
global scope within the OAM packet.
 
However we can use the LSP (or PW) label to identify which is the LSP (or PW)
that is misconnected.
When misconnection is detected, only the traffic received from the misconnected
LSP (or PW) needs to be discarded. The traffic received from others LSPs (or
PWs) is valid and can be forwarded.
 
Italo

  _____  

From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2008 4:22 PM
To: ext Italo Busi; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: MEAD team; [email-masked]
Subject: RE: [Mpls-interop] Connectivity Verification and Cotinuity Check
inMPLS-TP

Hi Ital,

I hope you enjoyed your vacation. 

Yes you are right. This was my intention.

If the MEP resides on the port then the LSP label is sufficient. 

However, I still have some concerns regarding the detection of misconnectivity
using LSP/PW labels. In a way labels are also local identifiers and not global
ones. Nothing prevent from another node to define the same label to a different
LSP and in a case of misconnectivity we may not detect it, from the same reason
as with the BFD discriminators...or maybe I miss something...

Best regards,

Nurit

  _____  

From: ext Italo Busi [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2008 17:04
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov (NSN - IL/Hod
HaSharon)
Cc: 'MEAD team'; [email-masked]
Subject: RE: [Mpls-interop] Connectivity Verification and Cotinuity Check
inMPLS-TP

Nurit,

Thanks, Italo

  _____  

Hi,

Best regards,

Nurit

  _____  

Hi all,

Best Regards,

Yaacov Weingarten

tel:     +972-9-775 1827

mob:   +972-54-220 0977

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Sep 2008 16:41:10 +0200

Hi Italo,

Thanks for the clarification.

So we need to select which of the three options listed below is the
preferred one. 

All, please advise.

Best regards,

Nurit

________________________________

From: ext Italo Busi [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2008 17:35
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov (NSN -
IL/Hod HaSharon)
Cc: 'MEAD team'; [email-masked]
Subject: RE: [Mpls-interop] Connectivity Verification and Cotinuity
Check inMPLS-TP

Nurit,

I fully agree with you: we cannot rely on the label to detect
misconnections.

In order to detect the misconnection we still need a unique identifier
with a global scope within the OAM packet.

However we can use the LSP (or PW) label to identify which is the LSP
(or PW) that is misconnected.

When misconnection is detected, only the traffic received from the
misconnected LSP (or PW) needs to be discarded. The traffic received
from others LSPs (or PWs) is valid and can be forwarded.

Italo

________________________________

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
	Sent: Tuesday, September 02, 2008 4:22 PM
	To: ext Italo Busi; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
	Cc: MEAD team; [email-masked]
	Subject: RE: [Mpls-interop] Connectivity Verification and
Cotinuity Check inMPLS-TP

	Hi Ital,

	However, I still have some concerns regarding the detection of
misconnectivity using LSP/PW labels. In a way labels are also local
identifiers and not global ones. Nothing prevent from another node to
define the same label to a different LSP and in a case of
misconnectivity we may not detect it, from the same reason as with the
BFD discriminators.....or maybe I miss something.....

	Best regards,

	Nurit

________________________________

	From: ext Italo Busi [mailto:[email-masked]] 
	Sent: Tuesday, September 02, 2008 17:04
	To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Weingarten, Yaacov
(NSN - IL/Hod HaSharon)
	Cc: 'MEAD team'; [email-masked]
	Subject: RE: [Mpls-interop] Connectivity Verification and
Cotinuity Check inMPLS-TP

	Nurit,

	if I understand well, you are asking which is the preferred
alternative for implementing CC&CV among the following three options:

	Thanks, Italo

________________________________

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)
		Sent: Sunday, August 31, 2008 2:42 PM
		To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
		Cc: MEAD team; [email-masked]
		Subject: Re: [Mpls-interop] Connectivity Verification
and Cotinuity Check inMPLS-TP

		Hi,

		I think that most of agree that there is no real
distinction between CC and CV and that we can combine both as CC & CV
function. Note that in G.8113 they are combined. 

		In order to do it (and in any case for the CV function)
we need to have a global identifier that identifies uniquely the
monitored path.

		BFD could be use for the CC function. The BFD session
identification (My Discriminator / Your Discriminator) has a local scope
by the two ends activating the session: the same discriminator values
may be used for a different path to be monitored by a different couple
of nodes in the same network.  When there are other means to identify
the path uniquely there is no need for the BFD session identifiers. For
example with VCCV-BFD the Discriminator fields are not used because the
PW label is sufficient to identify the BFD session. I think this is not
the case for LSP or TC. As the LSP label can be used from the interface
space (i.e. local to the interface) and in order to use it we need to
understand that the scope of the label is the interface and then use the
interface ID and the label ID as the identifier..... 

	[ib] I do not understand your argument here. An MPLS label (from
whichever label space) uniquely identifies the LSP or the PW. The label
space impacts only the way the label is looked up. When PHP is used, the
LSP endpoint does not receive any label that identifies the LSP and
therefore must rely on the BFD session identifiers. When PHP is not
used, the LSP label is present and uniquely identifies the LSP. In this
case I think that the LSP label can be used to identify the BFD session
like in VCCV-BFD.

	[ib] In both cases (PW and non PHP-ed LSP) you still need
connection identifiers with a global scope  in order to detect
misconnections. When the MPLS label is used to identify the LSP or the
PW a CC&CV packet belongs to, these identifiers can be checked against
an expected value: in this way it is possible to detect which LPS or PW
is misconnected.

		Since we want to have a similar operation for section,
PW/TC-PW, and LSP/TC-LSP and since that for the CV we need to rely on
identifiers uniquely assigned to a path, we need to define a mechanism
to have a unique identifier for the BFD session.

		We could for example change the semantic of the BFD
discriminators to have global scope, but we need to evaluate the case of
interoperability with MPLS BFD, etc. 

		We could also think of extending BFD and define an
optional global identifiers field.

		And of course we can define a new tool for the CC & CV
function.

		Please advice which tools should be used for the
combined CC&CV function and if it is BFD how can we have the global
identifiers.

		Best regards,

		Nurit

________________________________

		From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) 
		Sent: Monday, August 11, 2008 11:59
		To: [email-masked]
		Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)
		Subject: Connectivity Verification and Cotinuity Check
in MPLS-TP

		Hi all,

		In discussions between the authors of the OAM Analysis
and OAM Framework documents, the question was raised on the inherent
differences between the CC and CV operations and whether they are both
relevant for differentiation between on-demand and pro-active
activation.  The basic difference between the two operations is:

		*         CC - checks the "continuity" of the path
between two MEPs of an ME, there are tools available that perform CC
(e.g. BFD) using local identifiers for the ME check and therefore may be
subject for border-cases of inconsistency.

		*         CV - checks "connectivity" between the two
ends of the ME usually based on global identifiers, and may also give
path information, to verify that all MIPs are reacting correctly.

		It is unclear whether there is a need for "On-demand CC"
and "Pro-active CV" (and there are differences of opinion) or whether
the two operations complement each other in this characteristic.  We
would like to receive some feedback from the Service Providers on
whether there is a need to separate these two operations or whether it
wouldn't be best to just talk of - "pro-active CC &CV" as opposed to
"on-demand CC & CV", i.e. combining the functionality under one roof and
just differentiating between the pro-active (or continual) CC & CV
operation, and the on-demand (in reaction to a pro-active fault, or
during network periodic checks) CC & CV?

		Your comments and clarifications would be very much
appreciated,

		Best Regards,

		Yaacov Weingarten

		email:  [email-masked]
<mailto:[email-masked]> 

		tel:     +972-9-775 1827

		mob:   +972-54-220 0977

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Sep 2008 16:21:41 +0200

Hi Ital,

Best regards,

Nurit

Nurit,

if I understand well, you are asking which is the preferred alternative
for implementing CC&CV among the following three options:

Thanks, Italo

	Subject: Re: [Mpls-interop] Connectivity Verification and

	Hi,

	I think that most of agree that there is no real distinction
between CC and CV and that we can combine both as CC & CV function. Note
that in G.8113 they are combined. 

	In order to do it (and in any case for the CV function) we need
to have a global identifier that identifies uniquely the monitored path.

[ib] In both cases (PW and non PHP-ed LSP) you still need connection
identifiers with a global scope  in order to detect misconnections. When
the MPLS label is used to identify the LSP or the PW a CC&CV packet
belongs to, these identifiers can be checked against an expected value:
in this way it is possible to detect which LPS or PW is misconnected.

	Since we want to have a similar operation for section, PW/TC-PW,
and LSP/TC-LSP and since that for the CV we need to rely on identifiers
uniquely assigned to a path, we need to define a mechanism to have a
unique identifier for the BFD session.

	We could also think of extending BFD and define an optional
global identifiers field.

	Please advice which tools should be used for the combined CC&CV
function and if it is BFD how can we have the global identifiers.

	Best regards,

	Nurit

	From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) 
	Sent: Monday, August 11, 2008 11:59
	To: [email-masked]
	Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)
	Subject: Connectivity Verification and Cotinuity Check in
MPLS-TP

	Hi all,

	In discussions between the authors of the OAM Analysis and OAM
Framework documents, the question was raised on the inherent differences
between the CC and CV operations and whether they are both relevant for
differentiation between on-demand and pro-active activation.  The basic
difference between the two operations is:

	*         CC - checks the "continuity" of the path between two
MEPs of an ME, there are tools available that perform CC (e.g. BFD)
using local identifiers for the ME check and therefore may be subject
for border-cases of inconsistency.

	*         CV - checks "connectivity" between the two ends of the
ME usually based on global identifiers, and may also give path
information, to verify that all MIPs are reacting correctly.

	It is unclear whether there is a need for "On-demand CC" and
"Pro-active CV" (and there are differences of opinion) or whether the
two operations complement each other in this characteristic.  We would
like to receive some feedback from the Service Providers on whether
there is a need to separate these two operations or whether it wouldn't
be best to just talk of - "pro-active CC &CV" as opposed to "on-demand
CC & CV", i.e. combining the functionality under one roof and just
differentiating between the pro-active (or continual) CC & CV operation,
and the on-demand (in reaction to a pro-active fault, or during network
periodic checks) CC & CV?

	Best Regards,

	Yaacov Weingarten

	tel:     +972-9-775 1827

	mob:   +972-54-220 0977