On April 11, 2018 at 10:22:46 PM, Ahmed Bashandy (abashandy.i...@gmail.com) wrote:
Ahmed: Hi! How are you? I still have a couple of comments below…but nothing that should hold up process at this point. I’ll start the IETF Last Call. Thanks! Alvaro. .... M2.1.2. "At least one SRMS MUST be present in the routing domain. Multiple SRMSs SHOULD be present for redundancy.” These MUST|SHOULD seem to indicate a statement of fact. Again, from a specification point of view, what can be enforced? s/MUST|SHOULD/must|should. Note also that in 7.2 the text says that "Multiple SRMSs can be provisioned in a network for redundancy.”, which seems to be the right thing (no Normative language). #Ahmed I removed these two statements. Instead I modified the 3rd paragraph in Section 4.2 to indicate that there must be at least one SRMS server in the domain The modification of that 3rd paragraph now reads: "At least one SRMS server MUST exist in a routing domain…”, which really just moved the issue I was pointing to from 4.2.1 to 4.2. As I asked before, how can that “MUST” be enforced? Note that the sentence following this new text says: "Multiple SRMSs may be present in the same network (for redundancy).” I think that’s the right way to express what is needed (no Normative language). M2.2. Section 7.2. says that "a preference mechanism may also be used among SRMSs so to deploy a primary/secondary SRMS scheme”…but no other details are included. This document is where the SRMS is first defined, so I would expect this detail to also be included here. I note that Section 3.1. (SID Preference) of draft-ietf-spring-conflict-resolution contains the preference specification. Please move that section to this document. Ahmed: agreed. But since section 7.2 is under the manageability consideration, IMO it should really not contain much specification. Instead, I modified section 4.2.2 specify how to prefer SRMS advertisements and removed section 7.2 completely. Section 7.2 in version 11 is section 7.3 in version 10 Ok. I see that some of the text came from §3.1 in draft-ietf-spring-conflict-resolution, but not all of that section made it — specifically the part about the implicit preference values. Why? I didn’t check, but I’m assuming that the text that was moved here is not also in draft-ietf-spring-segment-routing-mpls. Is that true? .... M4. Security Considerations. I tend to agree that this document doesn’t introduce anything new…but it does specify something different. The base SR-related advertisement by an IGP is done for the segments belonging to the local node, but the SRMS lets a node (any node, multiple nodes) adverse any mapping (for nodes that may be anywhere in the network) which may result in conflicting advertisements (in the best case), or even false ones. Cryptographic authentication (any any other current security mechanisms in IGPs) only verify that the information was not changed, but it doesn’t validate the information itself, which can then lead to conflicting and or false advertisements, which could “compromise traffic forwarding”. You should at least recognize that the risk exists, even if no specific mitigation (except maybe strict configuration/programmability control by the operator) can be mentioned. #Ahmed: Agreed. Added text to indicate what you mentioned Thanks for adding some text…but I think you should still say more. The risk is of course that a rogue router can inject any mapping it wants: logging, control, etc..help avoid mistakes, but it doesn’t help in the case where the incorrect/false mapping is advertised on purpose. This last case is something I would like to see mentioned explicitly. .... P2. Please add References for "RSVP-TE, BGP 3107, VPNv4”. BTW, note that rfc3107 has been obsoleted by rfc8277 — you make references to “BGP3107” routes/label. #Ahmed Removed VPNv4 and added references to the others I think that by "BGP [RFC8277]” you really didn’t meant just “BGP”, but “BGP and Labeled Address Prefixes” (or something like that).. There are still 4 occurrences of “BGP3107".
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
