Hi Ruediger, Please see inline [Bruno]
From: [email protected] [mailto:[email protected]] Sent: Monday, June 26, 2017 8:52 AM To: [email protected] Cc: [email protected]; DECRAENE Bruno IMT/OLN; [email protected]; [email protected] Subject: AW: AD Review of draft-ietf-spring-oam-usecase-06 Hi Alvaro, we are fine, hope you are too - thanks for your review and comments. As we work with two editors, our comments are marked [ED]. [AR] Major: [AR] M1. The Introduction says that the monitoring system described in this document will be simplified “by enabling MPLS topology detection based on IGP signaled segments as specified by [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-idr-bgp-ls-segment-routing-ext]… This topology awareness can be used for OAM purposes as described by this document.” This sounds as if those extensions are critical to the monitoring system; IOW, Normative. However, the extensions are not mentioned in the document anymore, so I would think that the concept is what is important here, right? In lieu of making the references Normative, please consider simply generically referring to topology awareness in the Introduction (as you do elsewhere) and take the references out. [ED] The sentence is changed to: As compared to pre Segment Routing approaches, Segment Routing is expected to simplify such a monitoring system by enabling MPLS topology detection based on IGP signaled segments. The MPLS topology should be detected and correlated with the IGP topology, which is too detected by IGP signaling. [ED] Added IGP topology, as this is important or useful at least and wasn’t made explicit here. ############# M2. Section 12. (Security Considerations). This section seems to be just a random collection of thoughts, and not a well thought out description of potential threats and possible mitigation. Please take a look at rfc3552. I have some specific comments: 609 12. Security Considerations 611 As mentioned in the introduction, a PMS monitoring packet should 612 never leave the domain where it originated. What is the risk? How can it be mitigated? 612 It therefore should 613 never use stale MPLS or IGP routing information. I’m not sure if you mean that using stale information leads to leaking, or if not using it can prevent it. In either case, how can the PMS (or transit LSRs) recognize and prevent its use? 613 Further, assigning 614 different label ranges for different purposes may be useful. A well 615 known global service level range may be excluded for utilisation 616 within PMS measurement packets. Now you seem to be talking about isolation of the management traffic. Again, what are we avoiding here? I note that the text only says that this “may be useful”, so there are probably cases where it isn’t necessary – when, why? 616 These ideas shouldn't start a 617 discussion. They rather should point out, that such a discussion is 618 required when SR based OAM mechanisms like a SR are standardised. “shouldn’t start a discussion…[but] such a discussion is required…” Hmmm… “SR based OAM mechanisms like a SR” -- ?? It sounds like you’re trying to say that OAM mechanisms should consider something, what? Domain boundaries? Stale information? Isolation? I am a little confused, but this document “describes a system using MPLS data plane path monitoring capabilities” using SR – which I thought meant that no new SR based OAM mechanisms are to be standardized. Section 10 talks about potential extensions that are not part of what is presented here… What did I miss? 620 Should the approach of a PMS connected to an SR domain by a tunnel be 621 picked up, some fundamental MPLS security properties need to be 622 discussed. Picked up…?? Do you mean used, implemented, ?? What “fundamental MPLS security properties” are you referring to? Because you are describing approach here, this document is the place to at least mention those “fundamental MPLS security properties”. 622 MPLS domains so far allow to separate the MPLS network 623 from an IP network by allowing no tunneled MPLS access to an MPLS 624 domain. This does seem like a potential security issue. What are the risks? How can they be mitigated? [ED] You are right, the security discussion should be more precise. The text is hopefully better: The PMS builds packets with intent of performing OAM tasks. It uses address information based on topology information, rather than a protocol. The PMS allows to insert traffic into non-SR domains. This may be required in the case of an LDP domain attached to the SR domain, but it can be used to compromise security in the case of external IP domains and MPLS based VPNs. To avoid a PMS to insert traffic into an MPLS VPN domain, one or more sets of label ranges may be reserved for service labels within an SR domain. The PMS should be configured to reject usage of these service label values. In the same way, misuse of IP destination addresses is blocked if only IP-destination address values conforming to RFC 8029 are settable by the PMS. To limit potential misuse, access to a PMS needs to be authorized and should be logged. OAM supported by a PMS requires skilled personal and hence only experts requiring PMS access should be allowed to access such a system. It is recommended to directly attach a PMS to an SR domain. Connecting a PMS to an SR domain is technically possible, but adds further security issues. A tunnel based access of a PMS to an SR domain is not recommended. Traffic insertion by a PMS may be unintended, especially if the IGP or MPLS topology stored locally are in stale state. As soon as the PMS has an indication, that its IGP or MPLS topology are stale, it should stop operations involving network sections whose topology may not be accurate. Note however that it is a task of an OAM system to discover and locate network sections having where forwarding behavior is not matching control plane state. As soon as a PMS or an operator of a PMS has the impression, that the PMS topology information is stale, measures need to be taken to refresh the topology information. These measures should be part of the PMS design. Matching forwarding and control plane state by periodically automated execution of RFC 8029 mechanisms may be such a feature. Whenever network maintenance tasks are performed by operators, the PMS topology discovery should be started asynchronously after network maintenance has been finished. A PMS loosing network connectivity or crashing must remove all IGP and MPLS topology information prior to restarting operation. A PMS may operate routine measurements. If these are automated, care must be taken to avoid unintended traffic insertion. On the other hand, large scale operation based on operator configuration itself is a source of unintended misconfigurations and should be avoided. ######### M3. References - RFC4379 was obsoleted by RFC8029. Please update the references and check to make sure they are still valid. - I-D.ietf-spring-segment-routing should be Normative. [ED] Done in the draft. Minor: P1. Consider merging the Acronyms and Terminology sections – or at least putting both of them after the Introduction. I know that this would mean that some acronyms would have to be expanded in the Introduction. [ED] Next draft version. ####### P2. “BFD or LSP Ping format”…references? [ED] Next draft version. ####### P3. The reference to I-D.ietf-spring-sr-oam-requirement seems superfluous to me as there is no analysis to confirm that the requirements are met or even in line with the use cases presented – nor do I think there’s a need for that. [ED] Ok, we will remove the reference. ######## P4. Terminology P4.1. The definition of Continuity Check is copied exactly from rfc7276 – and there seems to be no special meaning when related to segment routing. Suggestion: just include a statement that the terminology in rfc7276 is used. [ED] Bruno asked us to better distinguish between CC and CV, that’s why both definitions were repeated. If Bruno is ok with your proposal to just refer to rfc 7276, I happily will do so. [Bruno] I’m fine with a reference to RFC 7276. Given that the terminology section of RFC 7276 is 10 pages long, I’d propose to also indicate the related section (i.e. RFC 7276 section 2.2.7) ######### P4.2. The definition of Connectivity Verification taken from rfc7276 doesn’t match what that RFC says; instead, it looks like the definition included here is a summary/interpretation. Suggestion: again, just reference rfc7276 as a whole – this will avoid definitions that don’t match. [ED] See above. If Bruno (or others) prefer to repeat the rfc7276 text, we’ll do so in both cases and adapt text to the original. If readers can be expected to have the definitions in mind, the bare reference is fine. [Bruno] idem. Thanks, --Bruno ########## P4.3. “RFC 4379 [RFC4379] specifies a Connectivity Verification for MPLS domains.” P4.3.1. RFC4379 has been obsoleted by RFC8029. [ED] Will be solved together with your M3 in the next draft version. ######### P4.3.2. I tried looking at those RFCs to figure out what was the purpose this seemingly random sentence is, knowing that the concepts from rfc7276 are the dominant ones, but couldn’t. Please consider rewriting or removing. [ED] Sentence P4.3. will be removed. ########## P4.3.3. Related – Section 5.1 says: “…should support RFC 4379 and its standardised extensions.” RFC4379 was updated by several RFCs, but RFC8029 isn’t. Does that change this phrase? Do you need to specifically point at which extensions are needed? [ED] Proposed rewording: The routers of the monitored domain should support RFC 8029 and [I-D.draft-ietf-mpls-spring-lsp-ping] to incorporate existing and coming standard MPLS trace route features. ########## P5. In 5.3: “Such a design is not within scope of this document.” What design? I guess you mean going through the details for those cases. If so, then we can get rid of this sentence. [ED] Sentence will be removed. ########### P6. Section 7: “In the above example…” You mean the one illustrated in Figure 1, right? [ED] Figure 1 will be referenced. “three IP Performance Measurement Work Group (IPPM WG) standard conformant Measurement Agents” Please reference the agents explicitly – no need to mention the WG. [ED] RFC6808 will be referenced. s/statistical test published by the IPPM WG[RFC6576]/statistical test in [RFC6576] [ED] OK. ############ P7. Section 9 (Connectivity Verification Using PMS). Section 3 already says that “This document proposes 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.” So it seems to me that this Section is not needed. The text doesn’t seem to provide anything more beyond that statement. [ED] Carlos, I think Nagendra proposed this text (but may be it was Nobo). I’ll check with Nagendra, I prefer removing the statement. ########### P8. Section 10. (Extensions of Specifications Relevant to this Use Case) also doesn’t seem to say much, specially because rfc4379 has already been obsoleted… [ED] Section will be removed. ########### Nits: N1. “pre Segment Routing” is used in several places, seemingly interchangeably with “non segment routing”. Please be consistent. Personally, I prefer “non segment routing”. [ED] Will be changed to “non” N2. s/as specified by specified by/as specified by [ED] Will be changed. N3. I find that the Introduction reads in parts like a marketing brochure. It would be ideal if you could reword and focus… [ED] Some Adjectives will be removed, but we’d prefer not to rewrite it all. N4. s/by RFC4379 (using the Downstream (Detailed) Mapping information resulting from a "tree trace", see [RFC4379]/by RFC4379 (using the Downstream (Detailed) Mapping information resulting from a "tree trace" Don’t need the second reference. [ED] 2nd ref will be removed. N5. s/T-LDP/tLDP The RFC Editor’s abbreviation list uses it that way. [https://www.rfc-editor.org/materials/abbrev.expansion.txt [ED] Will be changed. N6. s/Obviously/ [ED] Will be removed. _________________________________________________________________________________________________________________________ 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
