Subject: [PWE3] Question related to draft-mohan-pwe3-vccv-eth-00.txt

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 12 Jul 2006 00:16:53 +0200

Dinesh and all,
After having looked up the slides for the PWE3 session (which provide more info than the draft itself), I would like to ask a few questions.

1.	Neither the draft nor the presentation go into detail about the OAM PDU formats. But Y.1731 (referenced in both) specifies that CCM messages must carry MEP ID (2 octets) and MEG ID (48 octets). Since CCM messages are used, among other things, for frame/packet loss rate calculation, the following questions seem to be in place:

	*	How would MEG ID and MEP ID be used with EthOAM CCM PDUs carried in VCCV? 
	*	Is matching of MEG IDs for all the MEPs on the same PW required, and, if so, how should such a  match be achived for MS-PWs?
	*	Is uniqueness of MEP ID between of the MEPs on a given PW required and, if so, how will it be achieved among all the MEPs on a given MS-PW?

2.	Measurement of frame/packet loss rate proposed in Y.1731 requires insertion of counters of transmitted and received frames/packets when the OAM PDU is sent. draft-rosen-pwe3-congestion-03 explains why such an approach is highly problematic with PWs. Can you explain how do you intend to resolve this problem?
3.	A Note on Slide 11 says that using MEG Levels can help to implement Link Trace fot MS-PWs without using the PW label TTL. Can you please explain why an S-PE would inspect a PW packet below the PW label if (which resumably is required to identify the EthOAM PDU) if the TTL of the PW label is > 1?
4.	Slide 11 mentions remote management and data plane diagnostics as two functions supported with EthOAM but not with the other methods (LSP Ping). Can you please explain:

	*	What kind of "remote management" do you have in mind?
	*	Why the data plane diagnostics provided with LSP Ping is not sufficient?

IMHO answers to these questions would help to understand the scope of applicability of EthOAM PDUs in conjunction with PWs.

Regards,

                        Sasha

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 12 Jul 2006 01:08:41 +0200

Dinesh (and all),
Following a point raised in the disucssion: do you see the need for PWs over Ethernet PSN having more OAM functions than any other kind of PWs?
 
Regards,
                 Sasha

________________________________

From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Wed 7/12/2006 1:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: [PWE3] Question related to draft-mohan-pwe3-vccv-eth-00.txt

Dinesh and all,

Regards,

                        Sasha

---

From: "Dinesh Mohan" <[email-masked]>
Date: Tue, 11 Jul 2006 19:22:55 -0400

Sasha,
 
Please see inline:

Regards,
Dinesh 

From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 6:17 PM
To: Mohan, Dinesh (CAR:1A14)
Cc: [email-masked]
Subject: Question related to draft-mohan-pwe3-vccv-eth-00.txt

Dinesh and all,
After having looked up the slides for the PWE3 session (which provide
more info than the draft itself), I would like to ask a few questions.
[DM>>] As mentioned during my presentation, I had attempted to address
some of the comments and feedback I had received offline. I expect to
incorporate the feedback in next version. 

1.	Neither the draft nor the presentation go into detail about the
OAM PDU formats. But Y.1731 (referenced in both) specifies that CCM
messages must carry MEP ID (2 octets) and MEG ID (48 octets). Since CCM
messages are used, among other things, for frame/packet loss rate
calculation, the following questions seem to be in place: 

	*	How would MEG ID and MEP ID be used with EthOAM CCM PDUs
carried in VCCV? 
	*	Is matching of MEG IDs for all the MEPs on the same PW
required, and, if so, how should such a  match be achived for MS-PWs? 
	*	Is uniqueness of MEP ID between of the MEPs on a given
PW required and, if so, how will it be achieved among all the MEPs on a
given MS-PW?
		[DM>>] Some of these issues are related to MS-PW, which
as you correctly pointed out, is not currently covered in the draft. As
pointed during the presentation, these details are intended to be added
later for MS-PW applications but these details are orthogonal to the
proposal to carry Ethernet OAM as a possible payload in VCC.
Allocations of the MEP ID and MA/MEG IDs is an administrative issue,
similar to allocation of control plane elements e.g. PW IDs.

2.	Measurement of frame/packet loss rate proposed in Y.1731
requires insertion of counters of transmitted and received
frames/packets when the OAM PDU is sent. draft-rosen-pwe3-congestion-03
explains why such an approach is highly problematic with PWs. Can you
explain how do you intend to resolve this problem? 
	[DM>>] Ethernet OAM offers a toolkit and the functions can be
used when the information needed for these functions can be supported.
Again, the choice of functions to be used when deploying Ethernet OAM or
for that matter any OAM is a matter of choice for the users.  
3.	A Note on Slide 11 says that using MEG Levels can help to
implement Link Trace fot MS-PWs without using the PW label TTL. Can you
please explain why an S-PE would inspect a PW packet below the PW label
if (which resumably is required to identify the EthOAM PDU) if the TTL
of the PW label is > 1? 
	[DM>>] I did not get into the details for a MS-PW yet, however,
when Ethernet OAM payload is used, a S-PE which determines a frame as a
OAM payload (e.g. based on the CW nibble) can make the decision based on
the MA/MEG Level in Ethernet OAM payload. 
4.	Slide 11 mentions remote management and data plane diagnostics
as two functions supported with EthOAM but not with the other methods
(LSP Ping). Can you please explain: 

	*	What kind of "remote management" do you have in mind? 
		[DM>>] We have discussed during the development of
Ethernet OAM the application in access environments where remote
management e.g. carry out subscriber line test, can be initiated on
access node from a broadband gateway. 
	*	Why the data plane diagnostics provided with LSP Ping is
not sufficient?
		[DM>>] This might very well be a matter of
interpretations of diagnostics, however in Ethernet OAM, there are
provisions to using specific bit patterns (e.g. PRBS etc.), MTU sizes
etc which I am not sure are supported in LSP Ping. Of course, needless
to say that LSP Ping is likely not the payload choice when PSN is
non-MPLS.

IMHO answers to these questions would help to understand the scope of
applicability of EthOAM PDUs in conjunction with PWs. 

Regards,

                        Sasha

---

From: "Dinesh Mohan" <[email-masked]>
Date: Tue, 11 Jul 2006 19:32:37 -0400

Shasha,
 
If I understand your question correctly, you might be asking "do I think
that PWs over Ethernet PSN would require more OAM than PWs over other
PSNs"?, the answer is "No".  
 
However, I do feel that just because the OAM functions are not currently
offered across existing mechanisms does not imply that there is no need
for these functions. We have already experienced this recently during
the development of Ethernet OAM. Of course, care was taken not to
require entire functionality to be invoked when Ethernet OAM is to be
used. One can still pick and choose the functions that are needed in any
deployment.

Regards,
Dinesh

From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 7:09 PM
To: Mohan, Dinesh (CAR:1A14)
Cc: [email-masked]
Subject: RE: [PWE3] Question related to draft-mohan-pwe3-vccv-eth-00.txt

Dinesh (and all),
Following a point raised in the disucssion: do you see the need for PWs
over Ethernet PSN having more OAM functions than any other kind of PWs?
 
Regards,
                 Sasha

Dinesh and all,

Regards,

                        Sasha

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 12 Jul 2006 02:54:24 +0200

Dinesh,
Lots of thanks for a prompt response.
Please see some comments inline (bold maroon).
 
Regards,
                  Sasha

From: Dinesh Mohan [mailto:[email-masked]]
Sent: Wed 7/12/2006 2:22 AM
To: Sasha Vainshtein
Cc: [email-masked]
Subject: RE: Question related to draft-mohan-pwe3-vccv-eth-00.txt

Sasha,
 
Please see inline:

Regards,
Dinesh 

Dinesh and all,
After having looked up the slides for the PWE3 session (which provide more info than the draft itself), I would like to ask a few questions.
[DM>>] As mentioned during my presentation, I had attempted to address some of the comments and feedback I had received offline. I expect to incorporate the feedback in next version. 

	*	How would MEG ID and MEP ID be used with EthOAM CCM PDUs carried in VCCV? 
	*	Is matching of MEG IDs for all the MEPs on the same PW required, and, if so, how should such a  match be achived for MS-PWs? 
	*	Is uniqueness of MEP ID between of the MEPs on a given PW required and, if so, how will it be achieved among all the MEPs on a given MS-PW?
		[DM>>] Some of these issues are related to MS-PW, which as you correctly pointed out, is not currently covered in the draft. As pointed during the presentation, these details are intended to be added later for MS-PW applications but these details are orthogonal to the proposal to carry Ethernet OAM as a possible payload in VCC.  Allocations of the MEP ID and MA/MEG IDs is an administrative issue, similar to allocation of control plane elements e.g. PW IDs. [Sasha] This would mean double addressing and presumably require some kind of "address resolution protocol" IMHO (otherwise the most frequent problem detected would be mis-configuration:-)

2.	Measurement of frame/packet loss rate proposed in Y.1731 requires insertion of counters of transmitted and received frames/packets when the OAM PDU is sent. draft-rosen-pwe3-congestion-03 explains why such an approach is highly problematic with PWs. Can you explain how do you intend to resolve this problem? 
	[DM>>] Ethernet OAM offers a toolkit and the functions can be used when the information needed for these functions can be supported. Again, the choice of functions to be used when deploying Ethernet OAM or for that matter any OAM is a matter of choice for the users.  [Sasha] IMHO it is also a matter of support being provided by the vendors of PW-capable equipment. 
3.	A Note on Slide 11 says that using MEG Levels can help to implement Link Trace fot MS-PWs without using the PW label TTL. Can you please explain why an S-PE would inspect a PW packet below the PW label if (which resumably is required to identify the EthOAM PDU) if the TTL of the PW label is > 1? 
	[DM>>] I did not get into the details for a MS-PW yet, however, when Ethernet OAM payload is used, a S-PE which determines a frame as a OAM payload (e.g. based on the CW nibble) can make the decision based on the MA/MEG Level in Ethernet OAM payload. [Sasha] Do you expect S-PE to inspect each PW packet below the PW label to define whether it is an OAM packet? I am not sure this is a viable option with MPLS MS-PWs where S-PEs simply pop the transport label, swap the PW label and push a new transport label based on the (old) PW label... 
4.	Slide 11 mentions remote management and data plane diagnostics as two functions supported with EthOAM but not with the other methods (LSP Ping). Can you please explain: 

	*	What kind of "remote management" do you have in mind? 
		[DM>>] We have discussed during the development of Ethernet OAM the application in access environments where remote management e.g. carry out subscriber line test, can be initiated on access node from a broadband gateway. 
	*	Why the data plane diagnostics provided with LSP Ping is not sufficient?
		[DM>>] This might very well be a matter of interpretations of diagnostics, however in Ethernet OAM, there are provisions to using specific bit patterns (e.g. PRBS etc.), MTU sizes etc which I am not sure are supported in LSP Ping. Of course, needless to say that LSP Ping is likely not the payload choice when PSN is non-MPLS.

Regards,

                        Sasha

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 12 Jul 2006 14:56:42 -0400

Shasha,
 
Please see inline:
 
<snipped>

 Neither the draft nor the presentation go into detail about the OAM PDU
formats. But Y.1731 (referenced in both) specifies that CCM messages
must carry MEP ID (2 octets) and MEG ID (48 octets). Since CCM messages
are used, among other things, for frame/packet loss rate calculation,
the following questions seem to be in place: 

1.	

	*	How would MEG ID and MEP ID be used with EthOAM CCM PDUs
carried in VCCV? 
	*	Is matching of MEG IDs for all the MEPs on the same PW
required, and, if so, how should such a  match be achived for MS-PWs? 
	*	Is uniqueness of MEP ID between of the MEPs on a given
PW required and, if so, how will it be achieved among all the MEPs on a
given MS-PW?
		[DM>>] Some of these issues are related to MS-PW, which
as you correctly pointed out, is not currently covered in the draft. As
pointed during the presentation, these details are intended to be added
later for MS-PW applications but these details are orthogonal to the
proposal to carry Ethernet OAM as a possible payload in VCC.
Allocations of the MEP ID and MA/MEG IDs is an administrative issue,
similar to allocation of control plane elements e.g. PW IDs. [Sasha]
This would mean double addressing and presumably require some kind of
"address resolution protocol" IMHO (otherwise the most frequent problem
detected would be mis-configuration:-)
		[DM>>] [2] The application of CCM elements that you are
pointing out are relevant for detecting misconnections. From what you
are indicating as a concern, I am getting a sense that detection of
misconnections (where frames on data plane appear to be valid but are
actually misconnections) may not  be perceived as a requirement in your
model. Detection of misconfigurations is also important since the
misconfigurations should not occur in first place.    

2.	Measurement of frame/packet loss rate proposed in Y.1731
requires insertion of counters of transmitted and received
frames/packets when the OAM PDU is sent. draft-rosen-pwe3-congestion-03
explains why such an approach is highly problematic with PWs. Can you
explain how do you intend to resolve this problem? 
	[DM>>] Ethernet OAM offers a toolkit and the functions can be
used when the information needed for these functions can be supported.
Again, the choice of functions to be used when deploying Ethernet OAM or
for that matter any OAM is a matter of choice for the users.  [Sasha]
IMHO it is also a matter of support being provided by the vendors of
PW-capable equipment. 
	[DM>>] Sure, but we all know that when functionality is required
and is demanded by providers, vendors typically end up supporting it. 
3.	A Note on Slide 11 says that using MEG Levels can help to
implement Link Trace fot MS-PWs without using the PW label TTL. Can you
please explain why an S-PE would inspect a PW packet below the PW label
if (which resumably is required to identify the EthOAM PDU) if the TTL
of the PW label is > 1? 
	[DM>>] I did not get into the details for a MS-PW yet, however,
when Ethernet OAM payload is used, a S-PE which determines a frame as a
OAM payload (e.g. based on the CW nibble) can make the decision based on
the MA/MEG Level in Ethernet OAM payload. [Sasha] Do you expect S-PE to
inspect each PW packet below the PW label to define whether it is an OAM
packet? I am not sure this is a viable option with MPLS MS-PWs where
S-PEs simply pop the transport label, swap the PW label and push a new
transport label based on the (old) PW label... 

[DM>>] It seems to me that you are already pre-supporsing the solution.
As far as I can see, there are three modes for VCCV (TTL, CW nibble, and
Route Alert). Are you indicating that CW nibble option has not been
ruled out? 

1.	Slide 11 mentions remote management and data plane diagnostics
as two functions supported with EthOAM but not with the other methods
(LSP Ping). Can you please explain: 

Regards,

                        Sasha