Dear All,
I also support to work more on the node protection draft first, before
merging it with "basic rLFA spec", because of various reasons:
First, I think it would be almost a good approach to show how
node-protecting remote LFA works on the same, or almost the same sample
network topology used in the basic rLFA spec., but for easier and more
comprehensive understanding, a bit more complex but still simple example
should be given. IMHO, in the basic rLFA spec. it is a bit confusing
that node E is considered as a destination and this node is the next-hop
as well, since the important parts of the different roles are not
dissevering enough. Because of this, the similar example in node prot
spec. is also not straightforward:
"In the event of the node-failure on primary nexthop E, the alternate
path from Remote-LFA nexthop C to E and F also becomes unavailable."
According to the well-known last-hop problem, it is obvious that if the
destination (in the first case: node E) goes down, then it cannot be
protected. Moreover, since the example network topologyis not
2-node-connected, it is obvious again that the node F, which can be
accessed only via node E, then the failure of node E infers that the
node F can be never reached.
To (re)solve this issue, I suggest to use another network (in the basic
rLFA spec. as well), which could be the following (all link costs are
unit costs):
A----------B---------C
| | / |
| | / |
| | / |
F G / H
| | / |
| | / |
| | / |
D----------E---------S
In this case, assuming that source node S wants to send a packet to node
D, the next-hop of S is node E.
- Link protecting case: If link(s,e) fails, then P-space of node S
regarding to the failed link, would consist of node H,C,B and A, whilst
the Q-space of D would consist all nodes except S and H. In this case,
the PQ-nodes, as the possible repair tunnel endpoints, are node A,B and C.
- Node protecting case: However, if node E itself fails, then the
P-space of S would not alter, but the Q-space of D would only contain
node F and A resulting that only node A is present in the set of PQ-nodes.
I think that this network also shows the different between the node
protection and link protection, but in a more comprehensive manner. And
it also demonstrates the fact mentioned in Figure 2 that for
node-protecting rLFA, only the Q-spaces should be checked with those
distance functions.
Moreover, if we assume that in the example network above, there is a
link (A,E) and node E itself failed again, than PQ-space would be and
empty set meaning that this case cannot be protected.
Second, it would be better in the draft if the questions about "how
difficult or impossible to obtain those distances" would be clearly
stated in a bullet point list:
For example:
- Q-space can be obtained by rSPF calculated at destination node D
- P-space can be obtained through SPF calculation at source node S and
its 1-hop neighbor.
- SPF at a PQ-node is impossible or if not what extensions should be
implemented (actually, IMHO, this is the one, which is not clear enough)
Third, according to the Targeted-LDP discussion, which is about the fact
that if some node do not support TLDP, then how can be the inner MPLS
label obtained from the PQ-node; I think that if we want remote LFA
protection then the nodes MUST implement/support this feature, because
without this the protection cannot be guaranteed. For me, it is similar
to a hypothetic case for example of Not-via, where if the router do not
support Not-via, then it cannot be used. Or isn't it so simple?
Please comment my observations, in order to help me and may others as
well to understand every aspects and little pieces of remote LFA
specifications.
Best Regards,
Levente Csikor
On 10/08/2013 05:00 PM, Alvaro Retana (aretana) wrote:
On 10/8/13 7:33 AM, "[email protected]"
<[email protected]> wrote:
IMHO, it would make sense to wait maybe until IETF89 to decide about
merging node protect with basic rLFA spec.
I think we could progress quite fast on node protection and two IETF
meetings (88, 89) would be fine to have a good view and where we are on
node protection maturity. Then we may decide if merge is possible or not.
These two meetings would also permit to stabilize the rLFA base spec
details and have consensus on the required level of details that are
missing today.
I think now it's a bit early to decide ...
Feedbacks ? especially from chairs ?
Hi!
I agree that we need to first work on the node protection topic *before*
thinking about whether that should be merged onto the "basic rLFA spec".
There's not much point in arguing on where the text should go if we
haven't agreed on that first.
Also, we need to be conscious of the balance of progressing work vs
waiting for additional topics to be included in a draft. This is not a
statement one way or another, but the estimated timeline above really puts
us a year from now. OTOH, the discussions on the "basic spec" are still
ongoing (as to this morning) as well.
Alvaro.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
