Hi Mike,
I forgot to mention.. Even if we follow the below definition of Extended
P-Space from section 2 and 5.1.1.2 in RFC7490…
“Extended P-space:
Consider the set of neighbors of a router protecting a link.
Exclude from that set of routers the router reachable over the
protected link. The extended P-space of the protecting router
with respect to the protected link is the union of the P-spaces of
the neighbors in that set of neighbors with respect to the
protected link (see Section 5.2.1.2).
“
And
“The description in Section 5.2.1.1 calculated router S's P-space
rooted at S itself. However, since router S will only use a repair
path when it has detected the failure of the link S-E, the initial
hop of the repair path need not be subject to S's normal forwarding
decision process. Thus, the concept of extended P-space is
introduced. Router S's extended P-space is the union of the P-spaces
of each of S's neighbors (N). This may be calculated by computing an
SPT at each of S's neighbors (excluding E) and excising the subtree
reached via the path N->S->E. Note this will excise those routers
that are reachable through all ECMPs that include link S-E. The use
of extended P-space may allow router S to reach potential repair
tunnel endpoints that were otherwise unreachable. In cost terms, a
router (P) is in extended P-space if the shortest path cost N->P is
strictly less than the shortest path cost N->S->E->P. In other
words, once the packet is forced to N by S, it is a lower cost for it
to continue on to P by any path except one that takes it back to S
and then across the S->E link.
"
So if we apply the above definitions in the diagram below from the current
draft…
D1
/
S-x-E
/ / \
N---+ R3--D2
\ /
R1---R2
Then Ext-P-Space of S w.r.t S-E link cannot include E and D1 as SPT rooted at N
has ECMPs paths traversing the S-E link for destinations E and D1. Basically if
S forces a packet destined for E or D1 to N, N can send it back over the path
N->S-E. So once again E and D1 cannot be in PQ-space of S wrt S-E link.
Hope this resolves your comment :)
Thanks
-Pushpasis
From: Mike Shand
Date: Monday, October 5, 2015 at 6:35 PM
To: Pushpasis Sarkar
Cc: "[email protected]<mailto:[email protected]>", 'Jon Hudson', "Stewart Bryant
(stbryant)"
Subject: Re: Routing directorate QA review for
draft-ietf-rtgwg-rlfa-node-protection
Oh dear! Yes, that IS wrong. How did we miss that?
E is certainly in Q space as evidenced by the definition in 2.
The sentence you quote, I guess, is trying to say it is not any of the other
nodes other than C and D, and perhaps doesn't mention E because it is self
evidently included. E can clearly reach E without traversing SE.
It really MUST be included.
So for example in the topology
S---E
| /
N
E is in S's extended P-space AND in E's Q-space, and hence is a PQ point that
can be used to repair S-E. If E is omitted, no repair is possible, whereas it
clearly IS possible.
Sounds like an error report is in order:-(
Mike
On 05/10/2015 12:51, Pushpasis Sarkar wrote:
Hi Mike,
From: Mike Shand
Date: Friday, October 2, 2015 at 2:30 PM
To: Pushpasis Sarkar
Cc: "<mailto:[email protected]>[email protected]<mailto:[email protected]>", 'Jon Hudson'
Subject: Re: Routing directorate QA review for
draft-ietf-rtgwg-rlfa-node-protection
On 01/10/2015 18:49, Pushpasis Sarkar wrote:
Note that E itself is also in S's extended P space which makes this
>rather a strange example. It might be better to devise one where ONLY R3
>is in extended P space in order to avoid confusion.
[Pushpasis] But then E should not be in Q-Space(S-E) and hence it will not be a
PQ-node. The goal of this example was to show that while PQ node R2 provides
node protection for destination R3 and D2(in the text it says R1, I will
rectify it) the PQ-node R3 does not provide node-protection for the same
destinations R3 and D2. This example was specifically carved to show that not
only the path from PQ-node to destination must avoid primary next hop E, but
also all paths from S to the PQ-node as well.
Sorry, I don't understand. Surely E IS in Q-Space wrt S-E by definition.
[Pushpasis] Unless the text in RFC-7490 is not wrong, E is not included in
Q-Space(S-E). Here is the excerpt from section 5.2.1.3 that says E is not
included in Q-Space of (S-E) :-)
“
5.2.1.3. Q-space
The set of routers from which the node E can be reached, by normal
forwarding without traversing the link S-E, is termed the Q-space of
E with respect to the link S-E. The Q-space can be obtained by
computing a reverse Shortest Path Tree (rSPT) rooted at E, with the
subtree that might traverse the protected link S-E excised (i.e.,
those nodes that would send the packet via S-E plus those nodes that
have an ECMP set to E with one or more members of that ECMP set
traversing the protected link S-E). The rSPT uses the cost towards
the root rather than from it and yields the best paths towards the
root from other nodes in the network. In the case of Figure 1, the
Q-space of E with respect to S-E comprises nodes C and D only.
Expressed in cost terms, the set of routers {Q} are those for which
the shortest path cost Q<-E is strictly less than the shortest path
cost Q<-S<-E. In Figure 1, the intersection of the E's Q-space with
respect to S-E with S's P-space with respect to S-E defines the set
of viable repair tunnel endpoints, known as "PQ nodes". As can be
seen in the case of Figure 1, there is no common node and hence no
viable repair tunnel endpoint. However, when the extended P-space
(Section 5.2.1.2) at S with respect to S-E is considered, a suitable
intersection is found at C.
"
Thanks and Regards,
-Pushpasis
Yes, I understand the purpose of the example, and it serves that very well. I
just thought it may be confusing that the set of potential PQ nodes is greater
than you had described. That doesn't actually affect the point you are making
though.
Mike
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
