[spring] draft-ietf-spring-oam-usecase - shepherd review

[<[e-mail]>]

Hi authors,

As the document shepherd, I have reviewed draft-ietf-spring-oam-usecase-04.
Please find some comments below.

Best regards,
Bruno
---

===== Major comment
Multiple sections or text of the document seems to mix continuity check and connectivity verification. I think the document would be clearer if both points were more structured. e.g. introducing each, then explaining their interactions, then detailing each one independently, possibly in independent sub-section.

===== Minor comments
§2
"enabling MPLS topology detection based on IGP signaled segments as specified at [I-D.ietf-isis-segment-routing-extensions] and
   [I-D.ietf-ospf-segment-routing-extensions]."
You could probably add   draft-ietf-idr-bgp-ls-segment-routing-ext, as an external server is less likely to be part of the IGP.

----
"As compared to LDP, Segment Routing is expected to simplify the system by enabling MPLS topology detection based on IGP signaled segments"
I find the term "MPLS topology" loosely defined. As I read it, it could encompass:
- the network topology, which can be learnt by listening to the IGP, regardless of the use of LDP or Segment Routing
- MPLS signaling topology. With segment routing, it can be learnt by listening to IGP. For LDP, it would require looking at the LDP configuration or LDP status.
- MPLS signaled labels. With segment routing, it can be learnt by listening to IGP. For LDP, it would require one T-LDP session per node.

Could you please elaborate on what is exactly meant with "MPLS topology"?

---
One paragraph is about the use of SRMS in LDP network. "The system applies to monitoring of LDP LSP's ...."
Another paragraph is about the use of SRMS in pre-segment routing networks. "The MPLS path monitoring system described by this document can be realised with pre-Segment Routing (SR) based technology."

It's not crystal clear to mean what you mean by "pre-Segment Routing (SR) based technology." I could read "LDP", in which case, both paragraph are about the same subject. In which case, an editorial update would be useful to merge those two paragraphs, as they are related to the same case. (or at least very related)

---
"The system offers several benefits for network monitoring."
I would expect those benefits to be spelled out in the document. The sentence is indeed followed by a set of sentences, but it's not clear to me whether those sentences details those benefits or not. The first two sentences looks like benefits. The third one ["MPLS path trace function (whose specification and features are not part of this use case) is required, if the actual data plane of a router should be checked against its control plane.]", does not looks like a benefit to me.
Could you please highlight which are the specific benefits?

---
"MPLS path trace function (whose specification and features
   are not part of this use case) is required, if the actual data plane
   of a router should be checked against its control plane."

That sentence is 2 years old. Since then, has the MPLS WG progressed on this? If so, could you please indicate the related draft. If not, why?

And is this related to a further paragraph:
"   Documents discussing SR OAM requirements and possible solutions to
   allow SR usage as described by this document have been submitted
   already, see [I-D.ietf-spring-sr-oam-requirement] and
   [I-D.ietf-mpls-spring-lsp-ping]."

If so, both could probably be merged.
Any may be "already" is not appropriate for an RFC.

---
>From an editorial standpoint, I feel that the text mixes:
- the monitoring part, which is expected to be forwarded in the dataplane just like users packets.
- the trace/OAM features, which requires specific features on transit nodes, hence are not forwarded in the dataplane like users packets.

May be those 2 functions could be better distinguished in the text.

---
"By utilising the ECMP related tool set offered e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring system may:
   o  easily detect ECMP functionality and properties of paths at data level."
It's not clear to me what is meant by "properties"  nor "at data level".
Regarding detecting ECMP functionality, it could be detected with SR IGP extensions, both for layer 3 ECMP (adj_SID)  and layer 2 ECMP (draft-ietf-isis-l2bundles).
Or may be you mean load-balancing behavior over ECMP links/path. But this is not what is written.

---
"limit the MPLS label stack of an OAM packet to a minmum of 3 labels."
Do you mean :s/minmum/maximum

Why is this important?
- If this is a hard limitation on the SRMS, then the probing packets would also need to have a max of 3 labels. Which is typically not achievable.
- Why would the SRMS have such a limitation for a pure software based feature?

---
"It doesn't have to support any specialised protocol stack,"
What do you mean by this?
It does need to support the MPLS protocol stack, probably the IP protocol stack, the IGP protocol stack in order to learn the topology/labels, the LSP Ping protocol stack if OAM test are required....

---
"The MPLS monitoring servers are the single entities pushing monitoring packet label stacks."
may be
:s/single/only
:s/pushing/sending and receiving

---
"If the depth
   of label stacks to be pushed by a path monitoring system (PMS) are of
   concern for a domain, a dedicated server based path monitoring
   architecture allows limiting monitoring related label stack pushes to
   these servers."

If the limitation is on the PMS, as already expressed I don't see why a pure software packet sender would be limited in term of the number of labels (which are just bytes) sent. If the limitation is elsewhere, could you please elaborate.
The second part of the sentence could be rephrased for an easier understanding. (it took me 3 readings to guess that the important part is running the PMS on dedicated server. Although I'm even sure why using a software on a server solves the problem compared to using a software on the routing engine of a router (which may also be x86).

---
§3
"It can send pure monitoring packets"
What do you mean by "pure"?
>From the next sentence, I'd guess that you mean "monitoring packets with any payload"
---
"Segment
   Routing here is used as a means of adding label stacks and hence
   transport to standard MPLS OAM packets, which then detect
   correspondence of control and data plane of this (or any other
   addressed) path."

Could probably be better rephrased. e.g.

Segment Routing here is used as a mean of transporting probes or standard MPLS OAM packets, along any path. When MPLS OAM packets are used,    consistency between control and data plane may be checked.

---
"if the PMS is an IP host not connected to the MPLS domain,
   the PMS can send its probe with the list of SIDs/Labels onto a
   suitable tunnel providing an MPLS access to a router which is part of
   the monitored MPLS domain."

Probably some text should be added to cover this point. (e.g. the tunnel MUST be secured and provide authentication of the sender and cryptographic signature.
Also this has security implication as MPLS VPNs are based on the inability of the sender to send MPLS packet, while this option open this door. This should be discussed in the security consideration section.

----
§4.1

"To be able to work with the smallest possible SR label stack, first a suitable MPLS OAM method is used to detect the ECMP routed path between LER i to LER j which is to be monitored "
This is not very clear to me. Could this be rephrased? e.g. What to do mean by "MPLS OAM method?" Is this MPLS OAM API (e.g. LSP ping)? Is this an algorithm to define the path? (but the end of the sentence seems to indicate that the path is given as input "which is to be monitored") is "detect" the best term?

Also, this really the first sentence of the section. Could you first introduce the global picture and the goal, rather than starting with an optimisation "To be able to work with the smallest possible SR label stack"
---
"The packet will
   only reliably use the monitored path, if the label and address
   information used in combination with the MPLS OAM method of choice is
   identical to that of the monitoring packet."

   Could this be rephrased to improve clarity?
----
"The path PMS to LER i must be available." "The path LER j to PMS must be available."
Given that the goal is to monitor paths which are assumed to be available, if you detect a packet loss, how do you know which segment has an error? Indeed, packet loss could happen on this PMS to LERi path, while you think that you are measuring the path LER i to LER j.
---
"This path must be detectable"
What does this mean?

---
"If ECMP is deployed, it may be desired to measure along both possible paths which a packet may use between LER i and LER j."
- ECMP may be more than both.
- If you don't want to follow an ECMP path, why are you sending packet along an ECMP path? SR allows enforcing a single path among multiple ECMPs.

----
"Further changes in ECMP functionality at LER i will impact results."
Can you elaborate on this? Some LSR dynamically change their load-balancing behavior in order to try to equally spread the load on all ECMP paths. Is this behavior an issue? (i.e. are PMS and dynamic load-balancing adaptation mutually incompatible?)
Also if you want to monitor the (customer) ECMP path, would it be good to detect any change in this path, including a change trigger by such dynamic load-balancing adaptation?
And if you don't want to monitor the ECMP path, may be you should only monitor individual path.
----
"   Determining a path to be executed prior to a measurement may also be
   done by setting up a label stack including all Node SIDs along that
   path (if LSR1 has Node SID 40 in the example and it should be passed
   between LER i and LER j, the label stack is 20 - 40 - 30 - 10).  The
   advantage of this method is, that it does not involve MPLS OAM
   functionality and it is independent of ECMP functionalities."

   Adding all node SID do not remove ECMP functionnality. e.g. there could be multiple links between LSR1 and LER i.

  ---
  "Monitoring an MPLS domain by a PMS based on SR offers the option of
   monitoring complete MPLS domains with little effort and very
   excellent scalability."
Why is the scalability excellent? It looks to me that some links near the PMS will be "heavily" used to test all paths.
"little effort" is not very specific. IMHO a key benefit is the ability to monitor all network paths by deploying a single PMS, while some others techniques requires the deployment of many probes.

---
"The PMS does not require access to LSR/LER management interfaces "
The choice of the term "interfaces" seems debatble to me as it could be misread as physical interface being monitored. As the goal of this document is to monitor path and interfaces, I'd rather use "interface" only to refer to physical interface.
---
§4.2
Same comment: if the PMS detects loss of probe packets, it does not know whether the loss happens on the monitored bundle, or the path from the PMS to R2 or the path from R1 to the PMS.
So how do you compute/measure the characteristics of the sub-path (here the bundle) that you want to monitor?
---
§4.3
   "In the previous example, a uni-directional fault on the middle link
   in direction of R2 to R1 would be localized by sending the following
   two probes with respective segment lists:
   o  72, 662, 992, 664
   o  72, 663, 992, 664"


"The first probe would fail while the second would succeed."
I would have said the opposite as 663 maps to the middle link which is assumed to be faulty.

The formulation of the text is debatable as you are using the a priori knownledge of the failure in order to define the probes which needs to be sent.
More generally, as you are sending packets over a path longer than the one to be tested, what you need is to also monitor those extra sub-path in order to be able to check whether the failure is indeed on the sub-path that you want to test, rather than the paths from the PMS to the first node on the tested path, or the path from the last node on the tested path to the PMS.

---
§6
"Next: LDP or RSVP-TE label identifying the path to LER j at LER i.

if LER j is the ingress of the RSVP-TE LSP, LER j does not have a label identifying this LSP. Eventually, SR may allocate a binding SID to this RSVP-TE LSP.
if LER j is a transit LSR of the RSVP-TE LSP, how does the PMS learn this labels, which a priori is only know from LER j and its upstream LSR.

---
§7
"   MPLS SR topology awareness should allow the SID to monitor liveliness
   of most types of SIDs (this may not be recommendable if a SID
   identifies an inter domain interface)"

Why would it not be recommendable to monitor an inter domain SID/interface?
---
      "To match control plane information with data plane information, MPLS
   OAM functions as defined for example by RFC 4379 [RFC4379] should be
   enhanced to allow collection of data relevant to check all relevant
   types of Segment IDs."
Is there a document working on this? (e.g. draft-ietf-mpls-spring-lsp-ping ?) If so, it could be referenced.

---
§8
"While the PMS based use cases explained in Section 3 "
I think uses-cases are explained in section 4.
---
§6
"An implementation report on a PMS operating in an LDP domain is given in [I-D.leipnitz-spring-pms-implementation-report]"
This document is more than an implementation. IMHO it would deserve a short text introducing its scope and result. e.g.
"[I-D.leipnitz-spring-pms-implementation-report] present a PMS implementation report and compare delays measured with one PMS to the results of three IPPM standard conformant Measurement Agents, using the IPPM methodology as defined in [RFC6576].
The results show that the PMS measurements equal those captured by
   an IPPM conformant measurement system.  The ADK test is successful by
   comparing the measurement values of the round-trip delays for packets
   with a size of 64 bytes."

(but I'm not an IPPM expert, so authors should be able to provide a better text)

===== Nits
"IGP LSA"
LSA is not defined nor expanded on first use.
Plus it is protocol specific (OSPF). Could you cover both OSPF and IS-IS or use a term which is not protocol specific? Especially since a priori you mean LSDB analysis, rather than LSA.
---
:s/minmum/minimum
---
OLD: used as a means of adding label stacks and hence transport to standard MPLS OAM packets
NEW: used as a mean of adding label stacks and hence transport standard MPLS OAM packets to any node


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.