Hi Pushpasis,
On 10/9/15 15:26 , Pushpasis Sarkar wrote:
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.
you have to take into consideration the result of the behavior you are
proposing. The fact that traffic goes wrong may be a bigger issue than
you believe.
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.
same issue, there is no best-(re)originator, regardless of whatever
rules we use to choose it.
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? :)
there is other side of the coin too. The more complexity you add, more
difficult will it be to develop, deploy, maintain and support. So you
need to balance it with the gain you get.
thanks,
Peter
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
