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.
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.
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.
D. Same prefix originated with different index from same 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.
thanks,
Peter
Thanks
-Pushpasis
thanks,
Peter
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
