Subject: [mpls-tp] WG-LC comments on OAM Requirements document

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Jul 2009 13:36:28 +0200

Hi all,

I have the following comments to the latest version of the OAM
Requirements draft document.  The comments are listed in order of the
document sections, editorial comments are prefixed with an '[E]'.

1.	[E] Sec 1/first sentence - change "rationales" to "rationale"
2.	[E] Sec 1/second bullet - Not sure why the last statement
(starting with "Note that ...") is relevant to this paragraph,
especially since it appears again later in the document as part the
explanation for different requirements.  Suggest to delete this
statement.
3.	[E]Sec 1/last paragraph - in sentence starting with "For
example, ...", suggest deleting both appearances of the word
"application" - the statement will then read: "For example, connectivity
verification can be used for fault management by detecting failure
conditions, but may also be used for performance monitoring through its
contribution to the evaluation of performance metrics.."
4.	[E]Sec 2.1.1/first paragraph - should define (most probably in
sec 1.1) whether "bidirectional" refers to "co-routed bidirectional",
"associated bidirectional", or both.
5.	[E]Sec 2.1.3/first bullet - change "to operate the OAM functions
by relying on" to "to operate the OAM functions while relying on"
6.	Section 2.1.4 - Is it possible to define what
interoperability/interworking we are talking about?  Can we at least
give an example of a transport network that needs this
interoperability/interworking?  Is it just between different vendor
equipment/different network domains/different OAM tools/between the
different environments defined in section 2.1.3?  I think each of these
examples implies different requirements!
7.	Section 2.1.5/second paragraph - the text states a requirement
for "the capability to apply specific treatment to OAM packets, at the
nodes targeted by these OAM packets" - isn't there a need for
intermediate nodes (not targeted by the packets) to apply specific
treatment to OAM packets, e.g. to not redirect CC-V packets in cases of
failures along the normal PW/LSP while possibly redirecting service data
packets?
8.	[E]Sec 2.2/second paragraph - change "MUST allow for the ability
to support" to "MUST provide support for"
9.	Sec 2.2/second paragraph - this requirement is not very clear to
me.  Does this mean to imply that each tool that is proposed, e.g. a
protocol for CC and CV, and a separate protocol for PM and DM, must
provide for support of experimental functions?  Or is the implication
that there is one protocol that addresses all of the OAM functionality
and also experimental functions (which raises questions on the
consistency with sections 2.1.3 & 2.1.4)?  Or is this just a way of
referring to the GACH solution that appears in RFC5586?
10.	[E] Sec 2.2/third paragraph - remove the parenthetical "(s)" and
"(them)" the sentence starts in the singular and should just continue
that way!
11.	Sec 2.2/third paragraph - I assume that the word "choose" really
means "configure"?  Who is choosing this and why?
12.	Sec 2.2/fourth&fifth paragraphs - "It is RECOMMENDED that the
protocol solution" does this mean to imply that there is only one
protocol solution for all the functionality?  If not, then I suggest to
change it to "It is RECOMMENDED that any protocol solution".
13.	[E]Sec 2.2.1/third paragraph - change "The protocol solution(s)"
to "Protocol solutions..."
14.	Sec 2.2.3/third paragraph - the last statement (starts with
"This function SHOULD ...") seems to me to state that pro-active CV has
the same functionality as the CC function - can you please explain the
differences between the two?  It would help if you could give a detailed
explanation to differentiate between "Continuity" and "Connectivity" in
this context.
15.	[E]Sec 2.2.4/first paragraph - change "to enable the conduction
of diagnostic tests" to "to enable conducting diagnostic tests"
16.	[E]Sec 2.2.4/first paragraph - change "looping the traffic at an
Intermediate Point, back to the End Point it originates from" to
"looping the traffic at an Intermediate Point back to the originating
End Point" (including removing the ',')
17.	Sec 2.2.6 - Can you clarify which "forwarding traffic" is being
disabled - is it the OAM traffic, the service traffic, or both?  For
example is the CC traffic being locked out as well?
18.	Sec 2.2.7 - Can you clarify the use case for this function - it
seems from sec 2.2.6 that Lock is only performed at an End Point, so in
what situation does an Intermediate Point detect an "external lock
condition", and how does it detect it?  For OAM purposes, how is this
different from the function in section 2.2.8, and how does the
Intermediate Point differentiate between the two?
19.	Sec 2.2.8 and 2.2.9 - Is the only difference between these two
functions whether the originator is an End Point or an Intermediate
Point?  At one point there was a long discussion on the mailing list on
the need for Alarm Suppression/Alarm Reporting and I am not sure that
this is reflected in the document, can you clarify?
20.	Sec 2.2.10 - Isn't this functionality in slight contradiction to
the requirement in section 2.1.2 that the OAM SHOULD be independent of
the service being emulated?
21.	[E] Sec2.2.10/first paragraph - change "... a client defect of
fault condition ..." to "... a client defect or fault condition"
22.	[E] Sec2.2.11/last paragraph (also Sec 2.2.12/last paragraph)
change "rely on user-plane traffic to achieve that functionality" to
"rely on user-plane traffic to perform this functionality"
23.	[E] Sec 3 - is PSN a well-known acronym?
24.	[E] Sec 4/first paragraph - change "This document, as itself,"
to "This document, in itself," or "This document, by itself"

Hope this helps,

Best regards,
 
Yaacov Weingarten
Industry Environment, Carrier Ethernet
Nokia Siemens Networks
Hod Hasharon, Israel 45241
Tel: +972-9-775 1827
Mob: +972-54-220 0977

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Jul 2009 20:22:26 +0200

Hi Yaacov,

many thanks for your detailed review.
please see in-line.

regards,
-m

Weingarten, Yaacov (NSN - IL/Hod HaSharon) a écrit :
> 1.      [E] Sec 1/first sentence – change "rationales" to "rationale"

why? thx.
> 
> 2.      [E] Sec 1/second bullet – Not sure why the last statement 
> (starting with "Note that …") is relevant to this paragraph, especially 
> since it appears again later in the document as part the explanation for 
> different requirements.  Suggest to delete this statement.

This statement is relevant to the paragraph in the sense that it
talks about a transport service which is the subject of the whole
bullet.
> 
> 3.      [E]Sec 1/last paragraph – in sentence starting with "For 
> example, …", suggest deleting both appearances of the word "application" 
> – the statement will then read: "For example, connectivity verification 
> can be used for fault management by detecting failure conditions, but 
> may also be used for performance monitoring through its contribution to 
> the evaluation of performance metrics.."

ok, why not.
> 
> 4.      [E]Sec 2.1.1/first paragraph – should define (most probably in 

point already raised. I agree.
> 
> 5.      [E]Sec 2.1.3/first bullet – change "to operate the OAM functions 

for me "while" has a notion of time and can therefore give a meaning
(two different things done in parallel) which is not the intent of the
sentence. But I am not a native English speaker.
> 
> 6.      Section 2.1.4 – Is it possible to define what 

It is nearly impossible to be exhaustive concerning this item
as such the draft remained generic. See also my reply to Ben.
> 
> 7.      Section 2.1.5/second paragraph – the text states a requirement 
> nodes targeted by these OAM packets" – isn't there a need for 

I am not sure to understand. Are you talking about a specific solution?
> 
> 8.      [E]Sec 2.2/second paragraph – change "MUST allow for the ability 

I am not sure about this, for two reasons:
first, the sentence was agreed during mead call reviews,
second even if the objectives are similar, the written sentence
aims at giving an intrinsic (functional) capability to the protocol.
> 
> 9.      Sec 2.2/second paragraph – this requirement is not very clear to 

This first two readings are definitely not the intended ones.
The solution specified in RFC 5586 meets this requirement.
> 
> 10.     [E] Sec 2.2/third paragraph – remove the parenthetical "(s)" and 

ok.
> 
> 11.     Sec 2.2/third paragraph – I assume that the word "choose" really 

no, I would say that it is more equivalent to "decide".
"Configure" can have different meanings one of them being to
set the values of certain parameters. It was thus not used.
The sentence means that considering a given set of available
functions it must be possible to select which one to run and
which one not to run and on which entity (i.e. do not be forced
to run everything, everywhere by default).
The entity making the selection/choice and the reasons for that
are completely outside the scope of this document.
> 
> 12.     Sec 2.2/fourth&fifth paragraphs – "It is RECOMMENDED that the 

ok
> 
> 13.     [E]Sec 2.2.1/third paragraph – change "The protocol solution(s)" 
> to "Protocol solutions…"

ok
> 
> 14.     Sec 2.2.3/third paragraph – the last statement (starts with 
> "This function SHOULD …") seems to me to state that pro-active CV has 
> the same functionality as the CC function – can you please explain the 

no. It seems you are mixing the way the functionality is operated
and the functionality itself. It is not because two functionalities
can be operated the same way (e.g., pro-active e2e) that they are
the same.
CC & CV have been extensively discussed over and over again.
cc = Am I receiving traffic?
cv = Am I receiving traffic on the expected label and from the
expected point?
> 
> 15.     [E]Sec 2.2.4/first paragraph – change "to enable the conduction 

ok
> 
> 16.     [E]Sec 2.2.4/first paragraph – change "looping the traffic at an 

ok
> 
> 17.     Sec 2.2.6 – Can you clarify which "forwarding traffic" is being 
> disabled – is it the OAM traffic, the service traffic, or both?  For 

I understand your point, yet I fear that in this case we would start
dictating systems internal capabilities, which is outside the scope
of this document.
Nevertheless I would tend to say that client traffic is blocked.
> 
> 18.     Sec 2.2.7 – Can you clarify the use case for this function – it 

In the situation where an intermediate point is collocated with an end
point. How it detects it is system internal mechanisms, outside the
scope of the document.
It differs from 2.2.8 in the sense that the root cause is different.
> 
> 19.     Sec 2.2.8 and 2.2.9 – Is the only difference between these two 

It is effectively reflected.
What was said on the list was that OAM notifications should not be
cross-layer. As such it is not up to an end-point of a PW/LSP to report
a failure to client end-points but to the collocated functional
intermediate point to report this.
Alarm suppression could be a consequence of the operation of alarm
notification.
> 
> 20.     Sec 2.2.10 – Isn't this functionality in slight contradiction to 

no. independence is not isolation. Further this functionality is not
service specific.
> 
> 21.     [E] Sec2.2.10/first paragraph – change "… a client defect of 
> fault condition …" to "… a client defect or fault condition"

ok
> "rely on user-plane traffic to perform this functionality"

ok
> 
> 23.     [E] Sec 3 – is PSN a well-known acronym?

I would say yes, but will indeed expand.
> 
> 24.     [E] Sec 4/first paragraph – change "This document, as itself," 

ok
> 
> Hope this helps,
> 
> Best regards,
> 
>  
> 
> *//**/Yaacov Weingarten/*
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 19 Jul 2009 10:43:23 +0200

Martin, hi

Thank you for your replies (especially the ones that read "ok") my comments (on the other ones) are inline.

BR,
yaacov

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Friday, July 17, 2009 21:22
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] WG-LC comments on OAM Requirements document

Hi Yaacov,

regards,
-m

> 1.      [E] Sec 1/first sentence - change "rationales" to "rationale"

why? thx.
[yw>]  Because "rationale" is already a plural!
> (starting with "Note that ...") is relevant to this paragraph, especially 

This statement is relevant to the paragraph in the sense that it
talks about a transport service which is the subject of the whole
bullet
[yw>]  Yes, and the previous bullet is talking about a network operator that may be using the services of a different network and should be informed of problems in this sub-network.  Therefore the statement is just as relevant to the previous bullet, so why not add it there as well!
.
> example, ...", suggest deleting both appearances of the word "application" 
> - the statement will then read: "For example, connectivity verification 

ok, why not.

It is nearly impossible to be exhaustive concerning this item
as such the draft remained generic. See also my reply to Ben
[yw>] Nobody is requesting the document to be exhaustive - however, if people are expected to design solutions for these requirements, or to verify that solutions fulfill the requirements it is necessary to understand what is being required.
Regarding the discussion with Ben, I tend to agree with Ben and therefore I think that this entire topic needs more clarification.

In general, many of your answers seem to say that this document is intentionally vague, in order not to be limited to a particular solution.  However, I have the feeling that in various places it is so vague as to not qualify as a requirements specification.  The emphasis in that last statement is on the word "specification" which means that you need specifics of the requirements in order to design any real solution.
.

I am not sure to understand. Are you talking about a specific solution?
[yw>]   No, I am not talking about any specific solution, just trying to clarify whether the requirement states the full requirement.  To be more specific - in Section 4 you clearly state (last paragraph) "An OAM packet ... MUST NOT be forwarded beyond the End Point of" [the transport entity].  Yet there is no requirement anywhere in the document that the OAM packet MUST NOT be forwarded outside the transport entity somewhere in the intermediate nodes, as long as it arrives at the end-points!  And in fact the document seems to state that only the "targeted nodes" need to take special actions for OAM packets but intermediate nodes could take the same action as is taken for data packets.

I am not sure about this, for two reasons:
first, the sentence was agreed during mead call reviews,
second even if the objectives are similar, the written sentence
aims at giving an intrinsic (functional) capability to the protocol.
[yw>]  I very much object to the first of your two reasons - "agreed during mead call reviews".  While I understand the need for design teams in order to kick-start different activities within the IETF - the discussion of the design teams and in particular the MEAD discussions are closed to the general membership of the MPLS/CCAMP/PWE3 WG and while the members of this team may be very knowledgeable of the topics that are under discussion, they are in no way representative of all concerned parties.  In fact, the reason that the IETF process dictates the WG Last Call process is to allow the general membership to correct the actions of the design team!!  Therefore, to reject a comment on the basis of the mead discussion is counter to the purpose of the IETF process!!
In particular - the current statement is just cumbersome English, but it is just an editorial comment.

This first two readings are definitely not the intended ones.
The solution specified in RFC 5586 meets this requirement.
[yw>] 
If this is the case then I think that the paragraph should be rewritten to clarify what is meant.

ok.

[yw>] Again - so please clarify the text to state that what is being required is "The use of the any OAM function MUST be optional for any particular transport entity and it MUST be possible to select any subset (including the empty subset) of the functionalities to be applied to a particular transport entity."

ok

ok

[yw>] No I am not mixing up anything - I am just pointing out that there is no explanation similar to what you just supplied to explain the difference between these two functions.  That which the topic has been discussed "extensively" and yet the discussion is not reflected in the document is exactly where the problem lies.  There are many people that will read the document without being aware of the discussion.

ok

ok

I understand your point, yet I fear that in this case we would start
dictating systems internal capabilities, which is outside the scope
of this document.
[yw>] And therefore we are willing to accept behavior that is not acceptable because the requirement is not clearly stated?
Nevertheless I would tend to say that client traffic is blocked.

In the situation where an intermediate point is collocated with an end
point. How it detects it is system internal mechanisms, outside the
scope of the document.
It differs from 2.2.8 in the sense that the root cause is different.
[yw>] Your first statement here seems to imply that locking of one transport entity could affect traffic on a crossing transport entity?  Is this really the intention?  As to your differentiation from 2.2.8, I am not sure that I understand why the transport entity cares what the root cause is of "external" problems since it is not within the control of this transport entity to deal with the problem!!

ok

ok

ok