Many thanks for your detailed review, Alvaro! Alvaro, Bruno,
Please find inline a couple additional comments (also marked “ED”) in addition to the editor comments on Ruediger’s response. > On Jun 30, 2017, at 9:08 AM, [email protected] > <mailto:[email protected]> wrote: > > Hi Ruediger, > > Please see inline [Bruno] > > From: [email protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]>] > Sent: Monday, June 26, 2017 8:52 AM > To: [email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]>; DECRAENE Bruno > IMT/OLN; [email protected] <mailto:[email protected]>; > [email protected] > <mailto:[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] This was a great point, thank you. > [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. [ED] Good point as well. In addition to adding the references, we also add ICMP and S-BFD for completeness. > > ####### > > 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) > > [ED] Good point, Bruno. Done. > ######### > > 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. [ED] Ditto. > > 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. > > [ED] Section 9 revamped, and improved in content. We believe there is value in keeping it. > ########### > > 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 > <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. Thanks again, — Carlos Pignataro, [email protected] <mailto:[email protected]> “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
