Re: [spring] AD Review of draft-ietf-spring-segment-routing-ldp-interop-09

[Ahmed Bashandy <[e-mail]>]

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 
> ([e-mail] <mailto:[e-mail]>) 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".
>