Kals, > *Entry X: <10.1.2.0/24 <http://10.1.2.0/24>, 200, 20> *can be expanded up to *<10.1.21.0/24 <http://10.1.21.0/24>, 221>*
I think you are confusing SID with prefix. Those have nothing in common other then SID being "attached" to a prefix. In IP routing prefix with mask is usually NOT EXPANDABLE. When you advertise 10.1.2.0/24 it will better remain 10.1.2.0/24. Cheers, R. On Fri, Mar 17, 2017 at 11:27 AM, tech_kals Kals <[email protected]> wrote: > Hi Robert, > > As I have mentioned on the previous mail, there is a conflict on each > scenario. > > *Scenario 1: (Entries are conflicting with prefix)* > Entry *E1: <10.1.10.0/24 > <http://10.1.10.0/24>, 300, 22> *can be expanded up to *<10.1.31.0/24 > <http://10.1.31.0/24>, 321>* > Entry *E2: <10.1.1.0/24 > <http://10.1.1.0/24>, 150, 5> *can be expanded up to *<10.1.5.0/24 > <http://10.1.5.0/24>, 154>* > > * incoming entry is X:* > * Entry X: <10.1.2.0/24 > <http://10.1.2.0/24>, 200, 20> *can be expanded up to *<10.1.21.0/24 > <http://10.1.21.0/24>, 221>* > > entry-X prefix range *10.1.10.0 to 10.1.21.0 *would > conflict with entry *E1 *and *10.1.2.0 to 10.1.5.0* would conflict with > *E2*. > > *So, there is a prefix conflict.* > > > *Scenario 2: **(Entries are conflicting with SID)* > Entry *E1: <10.1.10.0/24 > <http://10.1.10.0/24>, 300, 22> *can be expanded up to *<10.1.31.0/24 > <http://10.1.31.0/24>, 321>* > Entry *E2: <7.1.1.0/24 <http://7.1.1.0/24>, > 280, 10> *can be expanded up to *<7.1.10.0/24 <http://7.1.10.0/24>, > 289>* > > * incoming entry is X:* > * Entry X: <3.1.1.0/24 <http://3.1.1.0/24>, > 285, 20> *can be expanded up to *<3.1.19.0/24 <http://3.1.19.0/24>, > 304>* > > entry-X SID *300 *to *304 *would conflict with entry > *E1 *and *SID 285 to 289* would conflict with *E2*. > > *So, there is a SID conflict.* > > *Scenario 3: **(Entries are conflicting with prefix and SID)* > > Entry *E1: <10.1.10.0/24 > <http://10.1.10.0/24>, 300, 22> *can be expanded up to *<10.1.31.0/24 > <http://10.1.31.0/24>, 321>* > Entry *E2: <5.1.1.0/24 <http://5.1.1.0/24>, > 190, 15> *can be expanded up to *<5.1.15.0/24 <http://5.1.15.0/24>, > 204>* > > * incoming entry is X:* > * Entry X: <10.1.1.0/24 > <http://10.1.1.0/24>, 200, 20> *can be expanded up to *<10.1.20.0/24 > <http://10.1.20.0/24>, 219>* > > entry-X prefix range *10.1.10.0 to 10.1.20.0 *would > conflict with entry *E1 and **SID 200 to 219* would conflict with *E2*. > > *So, there is a Prefix and SID conflict.* > > Regards, > _tech.kals_ > > On Fri, Mar 17, 2017 at 1:53 PM, Robert Raszuk <[email protected]> wrote: > >> Hi, >> >> Scenario 1 - I do not see any prefix conflict. Those are independent /24 >> prefixes. >> >> Scenario 2 - X IP prefix will be installed in RIB but SR labels (entire >> range) will be blocked for X. >> >> Scenario 3 - I do not see any prefix conflict. SR labels (entire range) >> will be blocked for X. >> >> Cheers, >> R. >> >> >> On Fri, Mar 17, 2017 at 9:09 AM, tech_kals Kals <[email protected]> >> wrote: >> >>> Hi Les, >>> >>> Sorry, I have not included my mapping entries in the previous mail. >>> Please see the example here below. >>> >>> I am working with the RFC which doesn't support *Preference Value, *so >>> please ignore it. And, my mapping entries would looks like. >>> Topology will be a single topology, not a Multi-topology and algorithm >>> would be SPF not CSPF. >>> >>> Please read my entry the below order: *<Prefix-start/ prefix-len, >>> starting SID, range>* >>> * E1 and E2 already configured Active entries. X is the newly incoming >>> entry.* >>> >>> >>> *Scenario 1: (Entries are conflicting with prefix)* >>> Entry *E1: <10.1.10.0/24 >>> <http://10.1.10.0/24>, 300, 22>* >>> Entry *E2: <10.1.1.0/24 >>> <http://10.1.1.0/24>, 150, 5>* >>> >>> * incoming entry is X:* >>> * Entry X: <10.1.2.0/24 >>> <http://10.1.2.0/24>, 200, 20>* >>> >>> * Step1: Conflict would be validated between E1 and X.* >>> >>> * Step2: Conflict would be validated between E2 and X.* >>> >>> * # what are the entries would be active and what will become >>> inactive/**excluded entry ?* >>> >>> >>> >>> *Scenario 2: **(Entries are conflicting with SID)* >>> Entry *E1: <10.1.10.0/24 >>> <http://10.1.10.0/24>, 300, 22>* >>> Entry *E2: <7.1.1.0/24 >>> <http://7.1.1.0/24>, 280, 10>* >>> >>> * incoming entry is X:* >>> * Entry X: <3.1.1.0/24 >>> <http://3.1.1.0/24>, 285, 20>* >>> >>> * Step1: Conflict would be validated between E1 and X.* >>> >>> * Step2: Conflict would be validated between E2 and X.* >>> >>> * # what are the entries would be active and what will become >>> inactive/**excluded entry ?* >>> >>> >>> *Scenario 3: **(Entries are conflicting with prefix and SID)* >>> >>> Entry *E1: <10.1.10.0/24 >>> <http://10.1.10.0/24>, 300, 22>* >>> Entry *E2: <5.1.1.0/24 >>> <http://5.1.1.0/24>, 190, 15>* >>> >>> * incoming entry is X:* >>> * Entry X: <10.1.1.0/24 >>> <http://10.1.1.0/24>, 200, 20>* >>> >>> * Step1: Conflict would be validated between E1 and X.* >>> >>> * Step2: Conflict would be validated between E2 and X.* >>> >>> *# what are the entries would be active and what will become >>> inactive/**excluded entry ?* >>> >>> >>> *Regards,* >>> *__tech.kals__* >>> >>> >>> On Fri, Mar 17, 2017 at 12:41 PM, Les Ginsberg (ginsberg) < >>> [email protected]> wrote: >>> >>>> It is not possible to answer your query because the way you have >>>> presented your entries (X, E1, E2, E3) does not tell us what conflicts you >>>> have. >>>> >>>> Do you have two SIDs assigned to the same prefix? (Prefix conflict) >>>> >>>> Do you have the same SID assigned to two different prefixes? (SID >>>> conflict) >>>> >>>> >>>> >>>> This matters – see Section 3.3.6 of the draft for an example as to why. >>>> >>>> >>>> >>>> Please present your example in the form defined in Section 3: >>>> >>>> >>>> >>>> Prf - Preference Value (See Section 3.1) >>>> >>>> Pi - Initial prefix >>>> >>>> Pe - End prefix >>>> >>>> L - Prefix length >>>> >>>> Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) >>>> >>>> Si - Initial SID value >>>> >>>> Se - End SID value >>>> >>>> R - Range value (See Note 1) >>>> >>>> T - Topology >>>> >>>> A - Algorithm >>>> >>>> >>>> >>>> A Mapping Entry is then the tuple: (Prf, Src, Pi/L, Si, R, T, A) >>>> >>>> >>>> >>>> Thanx. >>>> >>>> >>>> >>>> Les >>>> >>>> >>>> >>>> >>>> >>>> *From:* tech_kals Kals [mailto:[email protected]] >>>> *Sent:* Thursday, March 16, 2017 7:22 PM >>>> *To:* [email protected]; Les Ginsberg (ginsberg); Peter Psenak >>>> (ppsenak); Stefano Previdi (sprevidi); [email protected] >>>> *Subject:* [Mapping Server] Conflict Resolution >>>> >>>> >>>> >>>> Hi Experts, >>>> >>>> >>>> >>>> Could you please explain me what would be the expected behavior in >>>> the following scenario in *Quarantine approach*. >>>> >>>> >>>> >>>> Mapping entries *E1, E2, E3 *are Active entries. >>>> >>>> >>>> >>>> In case, if incoming new entry say *X *which has conflict with *E1, >>>> E2 and E3.* >>>> >>>> >>>> >>>> Assume, *X is better than E1 but not better than E2. ( E1 < X < E2)* >>>> >>>> >>>> >>>> * 1] X is better than E1 so E1 will become excluded entry and X will >>>> become an active entry* >>>> >>>> >>>> >>>> * 2] Now, X is compared with E2. E2 is better than X. So, X will >>>> become excluded entry and E2 is an active entry as it was.* >>>> >>>> >>>> >>>> *So, X and E1 will become "excluded entry".* >>>> >>>> >>>> >>>> *I couldn't find any info as shown above in the RFC. Can you please >>>> clarify ?* >>>> >>>> >>>> >>>> >>>> >>>> *My doubts:* >>>> >>>> *1) Will the entry become active only if it wins with all entries which >>>> are conflicted with this ?* >>>> >>>> *2) When doing conflict resolution with other entries, it can win with >>>> some entries and can lose to some? What could be the behavior ? * >>>> >>>> * - This is the case which I explained above.* >>>> >>>> * - In this case, X can become active by winning to E1 and lose E2 >>>> which leads X and E1 to become inactive/excluded entry.* >>>> >>>> >>>> >>>> >>>> >>>> can you please clarify ? >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> __tech.kals__ >>>> >>> >>> >>> _______________________________________________ >>> spring mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/spring >>> >>> >> >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
