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