Hello Greg, Thanks much for your responses, a few replies inline with GVP1> Thanks Prasad
-----Original Message----- From: Gregory Mirsky [mailto:[email protected]] Sent: Friday, March 25, 2016 1:00 AM To: Vengada Prasad Govindan (venggovi) <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected]; BIER ([email protected]) <[email protected]> Subject: RE: Comments regarding draft-ooamdt-rtgwg-oam-gap-analysis and draft-ooamdt-rtgwg-ooam-requirement 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 protected]] Sent: Thursday, March 24, 2016 1:36 AM To: [email protected] Cc: [email protected] 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. GVP1> It may be a good idea to list the telemetry requirements in the companion requirements draft, there are currently no references to it there. 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? GVP1> Yes. However I suggest that we consider the aspects of discovery of such paths to be reused for proactive OAM as well. Would be interested to know your thoughts on this aspect. 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. GVP1> Sure, but the active tail is not mandatory and making the response a MUST may be a tough requirement to match. 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. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
