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

<bruno.decraene@orange.com> Fri, 10 February 2017 17:45 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8A7124281; Fri, 10 Feb 2017 09:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJmX_gZfq5b1; Fri, 10 Feb 2017 09:45:25 -0800 (PST)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC5F1293EC; Fri, 10 Feb 2017 09:45:24 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id A9D52C04E1; Fri, 10 Feb 2017 18:45:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 7FA85180063; Fri, 10 Feb 2017 18:45:22 +0100 (CET)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0319.002; Fri, 10 Feb 2017 18:45:22 +0100
From: bruno.decraene@orange.com
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
Thread-Topic: draft-ietf-spring-oam-usecase - shepherd review
Thread-Index: AdJw331BkrJw6jV3SvW717QgrvEvbgNDdW3AAKavA0AAzyNMcA==
Date: Fri, 10 Feb 2017 17:45:21 +0000
Message-ID: <25080_1486748722_589DFC32_25080_2438_1_53C29892C857584299CBF5D05346208A1ED56C59@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <21e86564238c4f1d8cb225372b809f1d@HE101653.emea1.cds.t-internal.com>
In-Reply-To: <21e86564238c4f1d8cb225372b809f1d@HE101653.emea1.cds.t-internal.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A1ED56C59OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/P5FkKeKpnw7a62EsrKxdk_PRldw>
Cc: "spring@ietf.org" <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "draft-ietf-spring-oam-usecase@ietf.org" <draft-ietf-spring-oam-usecase@ietf.org>
Subject: Re: [spring] draft-ietf-spring-oam-usecase - shepherd review
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Feb 2017 17:45:30 -0000

Hi Ruediger,

Thanks for the answer and the updated draft which is indeed improved.

Reading the new version, I have additional comments below:


---
Idnits report 1 issue: "== It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages"
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-oam-usecase-05.txt

---
§2
"This document describes illustrates a system"
syntax error.

--
"   o  A single centralized MPLS monitoring system which is able to
      perform a continuity check (ping) along all Label Switched Paths
      of the SR domain.  Monitoring packets never leave data plane.

   o  The MPLS ping (or continuity check) packets never leave the MPLS
      data plane."

Two latest sentences seems redundant.

--
"Monitoring packets never leave data plane."
May be :s/data plane/user data plane

On my side, I'd see one addition advantage which does not seem to be mentioned:
since this is the same system sending and receiving the monitoring packet, the monitoring system may freely choose the payload of the packet. This allows sending probing packets representing real customer traffic, possibly from multiple service (e.g. small VoIP packet, larger HTTP packets), embedding useful monitoring data (e.g. accurate time stamps since both sender and receiver have the same clock, sequence numbers to ease the measurement...)

--
" o  An MPLS monitoring system, maybe several ones if redundancy is
      desired, which apply SR for OAM purposes as described, offer the
      possibilty to scale and design a flexible MPLS OAM platform as
      suitable for a provider."

I feel that the sentence could be rephrased to enhance its readability.
e.g. "Such MPLS monitoring system offer flexibility in term of deployment: from one single centralized one to a set of distributed systems (e.g. on a per region or service base), and in term of redundancy from 1+1 to N+1"

--
"construct ping packets respectively, which can be precisely steered to paths whose connectivity is to be checked, also if ECMP is present"
- I'm not sure what "respectively" refers to.
- may be :s/also if ECMP is present/including when ECMP is present
But feel free to disregard the comment as English is not my first language.

---
" If the
   depth of label stacks to be pushed for the purpose of path monitoring
   is of concern for a domain, a dedicated PMS server allows to push
   monitoring related label stacks of arbitrary depth on this server."

 Sentence is not easy to parse. I guess you mean:
 "If the monitoring of a specific topology/domain requires pushing a large label stack, one may use a software based implementation which is usually more flexible than an hardware based one."
 ---
  "RFC 4379 [RFC7276] specifies a Connectivity Verification for MPLS domains."
  Do you mean 4379 or 7276 or both? (I would assume :s/[RFC7276]/[RFC4379])

 ---
:s/As RFC 7276 sates/As RFC 7276 states
 ---
§3 Connectivity Verification.
 The below text seems duplicated:
"       RFC 7276 [RFC7276] defines Connectivity Verification as a
       mechanism to check connectivity between two nodes by checking
       whether a path between both can be used.  RFC 4379 [RFC7276]
       specifies a Connectivity Verification for MPLS domains.  As RFC
       7276 sates, Connectivity Verification and Continuity Checks are
       considered complementary mechanisms and are often used in
       conjunction with each other.  The use cases following merely
       treat SR based network monitoring as adding a new method to
       realise a Continuity Check.  In special cases, the SR based
       Continuity Check offers limited Connectivity Verification
       properties.  This will be in the use case descriptions, if
       applicable."

If so, one has to be removed.

---
OLD:
  "    The use cases following merely
       treat SR based network monitoring as adding a new method to
       realise a Continuity Check.  In special cases, the SR based
       Continuity Check offers limited Connectivity Verification
       properties.  This will be in the use case descriptions, if
       applicable."

Proposed rephrasing to improve readability
NEW
This document propose the use of SR based network monitoring as a new Continuity Check method. In some special cases, it also covers some limited Connectivity Verification. When applicable, this is indicated in the description of the use case.

---
OLD: a topology data base of MPLS SR domain to be monitored.
NEW: a topology data base of the MPLS SR domain to be monitored.

---
§5.1
" Finally, the PMS sets up and sends packets to monitor
   connectivity of the ECMP routed paths.  The PMS does this by creating
   a measurement packet with the following label stack (top to bottom):
   20 - 30 - 10.  The ping packets reliably use the monitored path, if
   the IP-address information which has been detected by the MPLS trace
   route is used as the IP destination address (note that this IP
   address isn't used or required for any IP routing)."

>From the first sentence, I'm understanding that the traceroute part is finished and now, end to end monitoring packets are sent using the regualr MPLS dataplane. In such context, I'm not following the latest sentence.
You are saying that the PMS sends a measurement packet with label stack 20 - 30 - 10 and IP destination address previously detected.
For me, such measurement packet will follow the path LERi (20), LERj (30), PMS (10). A priori the PSM will send capture back the packet, hence this packet will not be forwarded using the IP destination address. So why is this IP destination address important?


---
§5.1
" If correct forwarding
   along the desired paths has to be checked, or multiple physical
   connections exist between any two nodes, either additional
   information based on an MPLS trace route or additional Adj-SIDs are
   required to deal with ECMP."

You seem to want to avoid ECMP. In this case, why not using:
"a label stack including all Adj-SIDs along that path"
rather than
"a label stack including all Node-SIDs along that path"
?
That seems to do what you want (no ECMP), with no additional label/complexity required

---
§5.2
"R1 addresses Lx by the Adjacency SID 99x"

Notation "Lx" has never been used so far. I guess:
NEW: R1 addresses link x (Lx) by the Adjacency SID 99x

---
§5.2
" If the connected router
   is not SR compliant, a tunneling technique can be used to tunnel the
   probe and its MPLS stack to the first SR router. "

That detail has already been discussed elsewhere in the draft, so to improve clarity, I'd propose to remove that sentence.

---
§ 7
"The delay measurements of PMS and where compared based on a statistical test published by the IPPM WG [RFC6576]."
A word seems missing after "and".
Possible NEW: The delay measurements where compared based on a statistical test published by the IPPM WG [RFC6576].

---
§8
"MPLS SR topology awareness should allow the SID to monitor liveliness of SIDs"

May be you mean :s/should allow the SID/should allow the PMS
---
§8
The following rephrasing may be easier to read

OLD:
   To match control plane information with data plane information, MPLS
   OAM functions as defined for example by RFC4379 [RFC4379] are
   enhanced to allow collection of data relevant to check all relevant
   types of Segment IDs by [I-D.draft-ietf-mpls-spring-lsp-ping].

NEW:
   To match control plane information with data plane information
   for all relevant types of Segment IDs,
   [I-D.draft-ietf-mpls-spring-lsp-ping] enhance MPLS
   OAM functions defined by RFC4379 [RFC4379].


Thanks,
Regards,
Bruno

From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
Sent: Tuesday, February 07, 2017 9:55 AM
To: DECRAENE Bruno IMT/OLN
Cc: draft-ietf-spring-oam-usecase@ietf.org; spring@ietf.org; spring-chairs@ietf.org
Subject: WG: draft-ietf-spring-oam-usecase - shepherd review

Hi Bruno,

thanks for your thorough review. Your comments help to clarify how to use SR to improve monitoring of an MPLS domain. We've adapted text, there's some mostly minor discussion on a few issues. Comments are marked [RG] in your text below.

Version -05 has just been submitted.

Regards, Ruediger

Von: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> [mailto:bruno.decraene@orange.com]
Gesendet: Dienstag, 17. Januar 2017 17:35
An: draft-ietf-spring-oam-usecase@ietf.org<mailto:draft-ietf-spring-oam-usecase@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>; spring-chairs@ietf.org<mailto:spring-chairs@ietf.org>
Betreff: draft-ietf-spring-oam-usecase - shepherd review

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.

[RG] Good point, done (added section "Terminology").

===== 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.

[RG] Done.

----
"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"?

[RG] Again, good point, done (at least tried to..).

---
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)

[RG] Clarified sentence, moved text, added a reference to the section textt was moved to.

---
"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?

[RG] Good point, changed paragraph to bullet point list, focus is on "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?

[RG] Done.

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.

[RG] The statement has been changed. AFAIK the requirements cover more
than the features added by I-D.ietf-mpls-spring-lsp-ping. I think it's fair to
keep them separate. And I don't think it's up to the authors of the use
cases to decide about a merge.

---
>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.

[RG] Done.

---
"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?

[RG] Changed text and still like to maintain the idea of using no more than 3 labels as an
alternative to specify a path by labels only. MPLS trace is a fair option in the case
of multiple physical interfaces & ECMP between two nodes.

---
"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....

[RG] Changed the sentence. IP/MPLS packet formats need to be understood, packets must be built, sent and received, RFC4379 must be supported and IGP/MPLS topology should be maintained (i.e., IGP listening, SPF and optional correlation with MPLS traceroute). Static MPLS and IP routes do. Nothing else.

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

[RG] Changed the section and the sentence, added 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).

[RG] Changed the sentence, saying a server has no label stack depth limitations.

---
§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.

[RG] Good point, should be better phrased now.

---
"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.

[RG] Fair observation, I've added some text.

----
§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"

[RG] Rephrased the paragraph.

---
"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?

[RG] Rephrased the paragraph.
----
"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?

[RG]  Rephrased the paragraph.

---
"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.

[RG]  Rephrased the sentence.

----
"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.

[RG]  Rephrased the sentence.

----
"   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.

[RG]  You are right, added text.

   ---
  "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.

[RG]  Added text to clarify properties of the solution.

---
"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.

[RG]  Replaced "interfaces" by "plane information".
---
§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?

[RG]  You are right, added text.

---
§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.

[RG]  Thanks, added text and a generic statement addressing your second point. I don't want to describe a complete solution as part of a use case, I hope that's acceptable.

---
§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.

[RG]  I'm not an RSVP-TE expert.  Next:... says path from LER i to LER j (at LER i), in case of RSVP TE a tunnel would start in LER I and terminate in j. Changed text.
If that can't be settled, I don't care about RSVP-TE and I'd rather remove text than work on it.
---
§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?

[RG]  I'm sure that the principle works on interfaces within an IGP domain (and that what the use case offers). As with RSVP-TE, it may also work on inter domain SIDs, however I prefer not to have to discuss that in detail, as I didn't think it through. Hence, if someone (not me) provides  text on inter domain SID/interface or RSVP-TE. which is  acceptable to the chairs/IETF, I'm happy to add it. If this must be a scetch of workable solution, and I'm supposed to work it out, I'm not interested. I don't say, any of this is impossible or a bad idea. I don't have time to work on it.

---
      "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.

inter domain SID/interface

[RG] Done.
---
§8
"While the PMS based use cases explained in Section 3 "
I think uses-cases are explained in section 4.

[RG] Done.
---
§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)

[RG] Thanks for the positive feedback, done.


===== 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

[RG] Text has been removed or changed..



_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.