Re: [spring] draft-ginsberg-spring-conflict-resolution

Hi Les, Yes we come back to the Yang discussion :) I think the text you pointed is no more valid, as the consensus was to authorize per protocol configuration as a feature. I think we missed to update this definition part when we updated the model. Here is the augmentation for ISIS : augment

Re: [spring] draft-ginsberg-spring-conflict-resolution

Hi Robert, Regarding SRGB management, it’s really a design choice. There was already some discussion in the past. If people/implementations uses a global SRGB which is agnostic to protocols, cross protocol validation does not really make sense. If people/implementations uses per protocol SRGB,

Re: [spring] draft-ginsberg-spring-conflict-resolution

Stephane, IP addresses are not used in path computation. Those are just leaves. You can easily compute topology by just using nodes and links without IP addresses. SIDs should have semantics similar to IP address but presence of one should not mandate or be in any way tight to the other. Cheers,

Re: [spring] draft-ginsberg-spring-conflict-resolution

> On 8 Jan 2016, at 09:39, > wrote: > > [SLI] Anycast SID is not a conflict because the IP prefix is the same. Taking a long term view why conflate anycast SID with an IP address? SIDs are instructions not addresses, and we may

Re: [spring] draft-ginsberg-spring-conflict-resolution

Why not ... but in this case why also having Node-SID bound to a prefix ? Today Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a prefix. I agree that there is no real need to bind them to a prefix as long as we can still compute the path towards the SID (now we