Dear authors:
Hi! How are you?
I just finished reading this document. Thank you for using a more descriptive
name for this document.
I have some comments (please see below) that I would like to see addressed
before putting this document up for review by the IESG. I am however starting
the IETF Last Call with the understanding that my comments (and any other
received) will be addressed together.
Thanks!
Alvaro.
Major:
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.
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?
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.
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.
P2. “BFD or LSP Ping format”…references?
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.
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.
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.
P4.3. “RFC 4379 [RFC4379] specifies a Connectivity Verification for MPLS
domains.”
P4.3.1. RFC4379 has been obsoleted by RFC8029.
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.
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?
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.
P6. Section 7:
“In the above example…” You mean the one illustrated in Figure 1, right?
“three IP Performance Measurement Work Group (IPPM WG) standard conformant
Measurement Agents” Please reference the agents explicitly – no need to
mention the WG.
s/statistical test published by the IPPM WG[RFC6576]/statistical test in
[RFC6576]
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.
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…
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”.
N2. s/as specified by specified by/as specified by
N3. I find that the Introduction reads in parts like a marketing brochure. It
would be ideal if you could reword and focus…
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.
N5. s/T-LDP/tLDP
The RFC Editor’s abbreviation list uses it that way.
[https://www.rfc-editor.org/materials/abbrev.expansion.txt]
N6. s/Obviously/
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
