Subject: Re: [Bier] Comments regarding draft-ooamdt-rtgwg-oam-gap-analysis and draft-ooamdt-rtgwg-ooam-requirement

From: Gregory Mirsky <[email-masked]>
Date: Thu, 24 Mar 2016 19:29:43 +0000

Hi Prasad,
thank you for starting the discussion with your thorough review, thoughtful comments and questions. These will help us in our work on the documents. Please find my notes and responses in-line and tagged GIM>>. I'm sure other members of the design team will share their thoughts.

	Regards,
		Greg

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) [mailto:[email-masked]] 
Sent: Thursday, March 24, 2016 1:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Comments regarding draft-ooamdt-rtgwg-oam-gap-analysis and draft-ooamdt-rtgwg-ooam-requirement

Hello Authors, 
             Please consider the following comments:
    
I. draft-ooamdt-rtgwg-oam-gap-analysis-00

1) Security Considerations: Text does not reflect the scope of this work.
GIM>> Great catch. Will update in the next version.
2) Sec 2.3: Is Telemetry being considered in scope of this work? What is the motivation of this section in this document?
GIM>> Yes, the design team considers telemetry to be in scope of our work and we've plan to expand section 3.3 in the next revisions.
3) Sec 2.1.1.3 Not sure about the term SFP, Can you please explain/ expand it.
GIM>> Will expand Terminology section. SFP - Service Function Path.
4) Sec 2.1.1.1.  Proactive CC/CV in BIER: What is the motivation in specifying the packet formats (specifically for BIER, when other sections don't have similar figures)?
GIM>> Only because we had this done before the cut-off date. As we continue working, will be adding examples for other overlays or, if we see enough commonalities, may change structure of the document.
II. draft-ooamdt-rtgwg-ooam-requirement-00
1)
It may be nice to define a generalized layer model based on which the requirements are derived, while the layering may be specific to an overlay like NVO3/ EVPN the generic model may try to bring out the common aspects across the different technologies.
2)
Since there are specific sections to capture FM and PM requirements, it may be better to specify the respective requirements in their sections instead of clubbing them together. e.g. The following requirements seem to be candidates for this.
   REQ#4:  Overlay OAM MUST support proactive and on-demand OAM
            monitoring and measurement methods.

   REQ#5:  Overlay OAM MUST support unidirectional OAM methods, both
            continuity check and performance measurement.
GIM>> Thank you for the suggestion, we may use it in the next version.
3)
The requirement below may be a hard one to realize and limit the scalability of the solution.
   REQ#14: Overlay OAM MUST have the ability to discover and exercise
            equal cost multipath (ECMP) paths in its transport network.
GIM>> This particular requirement aimed at on-demand OAM rather than towards proactive tool. Do you think that making it more specific will help in identifying suitable tool and, if need to be, designing enhancement or new protocol?
4)
The requirement below may not hold true for multicast OAM, 

   REQ#7:  Overlay OAM MUST support bi-directional OAM methods.  Such
            OAM methods MAY combine in-band monitoring or measurement in
            forward direction and out-of-band notification in the
            reverse direction, i.e. from egress to ingress end point of
            the OAM test session.
GIM>> We had BFD for multi-point networks with active tails as an example for this requirement.
It may be worthwhile to consider separating requirements for unicast and multicast separately.
GIM>> I'd prefer to keep requirements, analyze gaps and provide solutions for general use cases as much as possible. In my view, the separation may be not between unicast and multicast but between one-way (uni-directional) and two-way (bi-directional) OAM. I view uni-directional unicast as special case of uni-directional multicast use case, though the latter does present scaling challenge.
5) Sec 4.3 AIS requirements: Can this section be merged with Sec 4.1 (FM requirements)
6) Sec 4.4: The term survivability may need some definition. If it is already defined in an earlier document, it may be nice to have a reference to it
GIM>> Thank you. Will add references to RFCs 3386 and 6372.