Hi Peter,
On 10/9/15, 2:58 PM, "Peter Psenak" <[email protected]> wrote: >Hi Pushpasis, > >On 10/9/15 12:33 , Pushpasis Sarkar wrote: >> Hi Peter, >> >> On 10/9/15, 11:34 AM, "Peter Psenak" <[email protected]> wrote: >> >> >>> Hi Pushpasis, >>> >>>>> >>>>> Node N1 in area 1 advertises prefix P1 with SID X. ABR1 advertises P1 to >>>>> area 0. >>>>> Node N2 in area 2 advertises prefix P2 with SID X, ABR2 advertises P2 to >>>>> area 0. >>>>> >>>>> Node 3 in area 0 get these two prefixes P1 and P2 from two different >>>>> ABRs. How does it know that the originators for P1 and P2 are different? >>>>> Do you expect the ABR1 and ABR2 to detect the collision and withdraw SID >>>>> advertisement to area 0? If yes, that may become source of all sorts of >>>>> problems. >>>> [Pushpasis] Nodes in area 0 can see that for the same prefix there are two >>>> prefix-sid advertisements from ABR1 and ABR2 but another advertisement >>>> (not re-advertisement) from Node 3. >>> >>> there is no advertisement from Node 3 in this case. Node 3 is an >>> internal router in area 0 (non-ABR). How does node 3 figures out if the >>> prefixes P1 and P2 are sourced by the same node or not? Unless you carry >>> the originator-id with each prefix, I don't see how you can do that. >> >> [Pushpasis] I overlooked that there were two different prefixes P1 and P2 in >> your example. In that case I will take back my last comment and re-formulate >> the proposal. For the situation that you mentioned above, here is what how >> it should be dealt with.. >> 1. ABR1 and ABR 2 re-advertises the prefixes P1 and P2 into Area 0. >> 2. ABR1 will learn from ABR2’s advertisement in Area 0 that the same index >> is associated with P1 originated by N1 in Area 1 and and a different prefix >> P2 (re)originated from another node ABR2 in Area 0. It should then raise a >> syslog error notifying that this seems to be misconfiguration. >> 3. Likewise, ABR2 will learn from ABR1’s advertisement in Area 0 that the >> same index is associated with P2 originated by N2 in Area 2 and and a >> different prefix P1 (re)originated from another node ABR1 in Area 0. It >> should then raise a syslog error notifying that this seems to be >> misconfiguration. >> 4. And then none of the ABRs should withdraw the prefix-sid-advertisements >> (I take back my last comment). Things should be left as is till the operator >> rectifies the configuration. > >the question is what Node 3 does? If it assumes that thees are coming >from same originator, it may end up sending the traffic wrong way, which >a serious issue. [Pushpasis]Node 3 should follow rule D below. For the ingress traffic at Node 3, it will choose the next-hop towards ABR1 and for P1 and the next hop towards ABR2 for P2. However for the transit route for SID X, it has to choose who is the best-originator (among ABR1 and ABR2) for SID X, and choose the nexthop towards the same. The resulting traffic path may not still be right. But the protocol should not take care of it other than throwing a syslog/error-message. Operator should rectify the misconfiguration. > >> >> The basic rule for any node to detect a anomaly and take action should be as >> follows… >> A. Multiple prefix originated with same but from same originator.. No need >> to throw error > >we do not seem to have a consistent way to detect the same originator, >unless we advertise originator with every prefix. > >> B. Multiple prefix originated with same index but from different >> originator.. Throw syslog.. Use the index advertised with >> best-originator(s) of the prefix for MPLS ingress/transit routes. > >there is no best-originator, that is the whole point. [Pushpasis]I meant best-(re)originators. So for nodes in Area 0 ABR1 and ABR2 are the (re)originators. > >> C. Same prefix originated with different index from same originator.. Throw >> syslog.. But don’t program MPLS ingress/transit routes for it… Ideally this >> scenario is almost next to impossible unless any implementation allows >> assoicating multiple sids with a singe prefix. > >we should not make the behavior implementation specific. [Pushpasis] Fully agree. That is why I am asking the draft to spell out the expected behavior explicitly. So that all implementations can follow the same behavior. > >> D. Same prefix originated with different index from different originator.. >> Throw syslog.. Use the index advertised with best-originator(s) of the >> prefixfor MPLS ingress/transit routes. >> >> Hoping I have covered all possible situation with the above set of rules. > >the question really is if the above is worth the benefit you get. >It seems that simplicity may be a better option here. [Pushpasis] Often simplicity in implementation also brings a lot of limitations along with. We need to always draw the line somewhere in the middle, and strike a balance between simplicity of the implementation and usability it offers to the end-users. If simplicity limits a user from deploying the solution in his/her existing network, what use is that implementation? :) I have already mentioned in a previous mail about the limitation ‘per-prefix-unique-sid-index’ approach brings. And I won’t be repeating myself again and again on this thread anymore. Thanks -Pushpasis > >thanks, >Peter > > >> >> Thanks >> -Pushpasis >> >> >>> >>> thanks, >>> Peter > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
