Hi
Thanks for the review
See reply to the comment at #Ahmed
Ahmed
On 6/20/18 9:40 AM, Benjamin Kaduk wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-spring-segment-routing-ldp-interop-13: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I may be missing something, but I don't see anything that says whether the
preference field introduced in Section 3.2.3 uses larger values or smaller
values for more-preferred SRMSes.
#Ahmed:
If I understand this statement correctly, the concern is about which
label(s) get assigned to which prefix(es). This concern is addressed as
follows
From the MPLS architecture point of view, there is nothing wrong in
having multiple labels for the same prefix. Segment routing in general
and this document in particular did not introduce this behavior nor did
they prohibit/restrict/relax it. For example, an implementation that
allows the operator to locally assign multiple local labels to the same
prefix may continue to apply this behavior whether the platform supports
segment routing or not, in which case it is up to the implementation
and/or the configuration affecting the MPLS forwarding plane to specify
how to behave when multiple labels are assigned to the same prefix. Such
behavior is a general MPLS behavior that outside the scope of and is not
modified by segment routing.
However the opposite, where the same label gets assigned to multiple
prefixes resulting in label collision is problematic. This document
prohibits label collision resulting from the use of SRMS (which is
introduced by this document) in the first bullet starting at the 3rd
line of page 12:
"- If there is an incoming label collision as specified in
[I-D.ietf-spring-segment-routing-mpls] , apply the steps specified
in [I-D.ietf-spring-segment-routing-mpls] to resolve the
collision.""
The introduction of the SRMS is also introducing a new way for a protocol
participant to make claims about route prefixes directed at "third parties"
(non-MS, non-MC routers). While routing protocols in general do require high
levels of trust in all participants in order for proper routing to occur, this
addition seems to create a "first among equals" situation that could be called
out more clearly in the security considerations. (I do appreciate that the
requirement for preferring SIDs advertised in prefix reachability
advertisements over those advertised in mapping server advertisements does help
alleviate some of the risk.)
#Ahmed:
If I understand your comment, the concern is about
"first-come-first-serve" behavior. I believe this concern is addressed
as follows
(1) The sentence starting at the fourth line of the second paragraph in
page 10 says:
For a given prefix, if an MC receives an SR mapping advertisement
from a mapping server and also has received a prefix-SID
advertisement for that same prefix in a prefix reachability
advertisement, then the MC MUST prefer the SID advertised in the
prefix reachability advertisement over the mapping server
advertisement i.e., the mapping server advertisment MUST be ignored
for that prefix.
(2) The last bullet at the bottom of page 11 says:
- For any prefix for which it did not receive a prefix-SID
advertisement, the MCC applies the SRMS mapping advertisments with
the highest preference.
(3) The first bullet near the top pf page 12 says:
- If there is an incoming label collision as specified in
[I-D.ietf-spring-segment-routing-mpls] , apply the steps specified
in [I-D.ietf-spring-segment-routing-mpls] to resolve the
collision.
So for the same set of received advertisements (SRMS advertisements,
prefix-SID advertisements, or combination of both), the same set of
labels will be assigned to the same prefix. As mentioned in my previous
comments, if multiple labels get assigned to the same prefix, the
behavior is not related to segment routing
Regarding placing a comment in the security section, IMO a specification
of which advertisement(s) to use when receiving multiple (conflicting or
non-conflicting) advertisements has nothing to do with security. It is
an externally visible protocol(s) behavior that should be specified in
the sections covering the protocol(s) themselves rather than security
consideration of the protocol(s).
But if you still think there is a need to mention something in the
security section, a suggestion from your side will be greatly appreciated .
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I support Alissa's suggestion about the text covering cryptographic
authentication.
#Ahmed: I modified the statement as Alissa suggested in version 14 that
will be published in the next 1-2 days
"[100,300]" and "(100,200)" are each used as an example SRGB. In
some contexts the round versus square brackets indicate a
distinction between "closed" (includes endpoints) and "open" (does
not include endpoints) intervals. If there's no need to make such a
distinction, I suggest standardizing one one format.
#Ahmed: I changed both of them to use [] in version because we mean
inclusive
As was mentioned in the secdir review, it would be good to expand FEC and LFA
on first usage.
#Ahmed: Corrected in version 14 that will be published in the next 1-2 days
Section 1
Section 2 describes the co-existence of SR with other MPLS Control
Plane. [...]
nit: "other MPLS Control Plane" seems to be an incomplete compound noun
-- is it other control plane technologies that are being considered?
#Ahmed: I added "protocols" in version 14 to clarify that
Section 2
Note that this static label allocation capability of the label
manager exists for many years across several vendors and hence is not
new. Furthermore, note that the label-manager ability to statically
allocate a range of labels to a specific application is not new
either. [...]
nits: "has existed", "label-manager's ability".
#Ahmed: Corrected (thanks a lot)
Section 2.1
MPLS2MPLS refers the forwarding behavior where a router receives an
labeled packet and switches it out as a labeled packet. Several
nit: "refers to", "a labeled packet"
#Ahmed: Corrected
Section 3.2
This section defines the Segment Routing Mapping Server (SRMS). The
SRMS is a IGP node advertising mapping between Segment Identifiers
(SID) and prefixes advertised by other IGP nodes. The SRMS uses a
dedicated IGP extension (IS-IS, OSPF and OSPFv3) which is protocol
specific and defined in [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions], and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
nit: Perhaps "IS-IS, OSPFv2, and OSPFv3 are currently supported" is a
better parenthetical?
#Ahmed: Corrected in the next version
The example diagram depicted in Figure 3 assumes that the operator
configures P5 to act as a Segment Routing Mapping Server (SRMS) and
advertises the following mappings: (P7, 107), (P8, 108), (PE3, 103)
and (PE4, 104).
nit: I think this is Figure 2.
#Ahmed: Corrected in the next version
Section 3.2.1
[...] Examples
of explicit prefix-SID advertisment are the prefix-SID sub-TLVs
defined in ([I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions], and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
Would draft-ietf-idr-bgp-prefix-sid (also on this week's telechat)
be appropriate for inclusion in this list?
for that prefix. Hence assigning a prefix-SID to a prefix using the
SRMS functionality does not preclude assigning the same or different
prefix-SID(s) to the same prefix using explict prefix-SID
advertisement such as the aforementioned prefix-SID sub-TLV.
#Ahmed: The SRMS functionality is specific to IGPs as mentioned in the
second sentence of the second paragraph in Section 3.2
nit: I think the aforementioned things were a list, so "sub-TLVs" plural
would be appropriate.
Including the name for IS-IS TLV 135 might be helpful for the
reader.
#Ahmed: Corrected as suggested in the next version
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
