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.decra...@orange.com<mailto:bruno.decra...@orange.com> [mailto:bruno.decra...@orange.com] Gesendet: Dienstag, 17. Januar 2017 17:35 An: draft-ietf-spring-oam-usec...@ietf.org<mailto:draft-ietf-spring-oam-usec...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org>; spring-cha...@ietf.org<mailto:spring-cha...@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.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
