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.
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.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
