Thanks you very much
I will take care of the comments below in the next version that I plan
to put out in next week
Ahmed
On 5/10/18 1:41 PM, Alvaro Retana wrote:
On April 11, 2018 at 10:22:46 PM, Ahmed Bashandy
([email protected] <mailto:[email protected]>) 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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
