Subject: [mpls] Thoughts on draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 4 Jul 2013 08:45:17 +0000

Hi there

Here are my thoughts on this draft.  My apologies if this duplicates what anyone else has already said, I have not read all the other comments.

Regards
Jon

1. Applicability of this solution
As I think has been mentioned elsewhere, PCE provides a superior solution to this problem since it can produce an end-to-end optimized tree without the need for guesswork and crankback.  I assume you believe that there are scenarios that the PCE solution is not applicable to.  Please could the draft explain what those scenarios are?

2. Comments on proposed mechanism
Some of the recommendations made by the draft seem to me to be counter-productive.

In section 3.1 "It is RECOMMENDED that the ingress node of a P2MP LSP selects the same ingress border node in the loose hop ERO for all sibling S2L sub-LSPs that transit through a given domain."  By doing this you can eliminate from consideration more preferable S2L paths by forcing them all through a single border node.  Even if this recommendation is followed, there is no guarantee that you have eliminated or even reduced the potential number of merge points.  I don't think this behaviour should be recommended.

In section 3.2 "If an ingress border node on the path of the P2MP LSP is unable to find a route that can supply the required resources or that is re-merge free, it MUST generate a PathErr message for the subset of the S2L sub-LSPs which it is not able to route."   The implication is that the border node's first priority is to find any remerge-free route, no matter how sub-optimal.  Only if no such route can be found, should it crank back.  This seems wrong.  In fact I think the border node's priorities should be inverted.  Each detected remerge is an opportunity to optimize the data plane so that more leaf nodes are reached via a common path.  Rather than avoiding a remerge at all costs (by maximising the number of paths) we should aim to find remerges so that we can prune unnecessary paths.

*         If the most preferable path for an S2L LSP involves a remerge then the leaf nodes that are involved in the merge should be moved onto a common path.  I can see no advantage to looking for a less-preferable path without a remerge in this scenario.

*         If the most preferable path for an S2L LSP does not involve a remerge, but there is a less-preferred path that does involve a remerge, then the domain's operator may still (by policy) choose to move all the leaf nodes onto a common path through the remerge node, for example if they are particularly concerned about carrying each packet twice, or if by doing so it leads to a lower overall cumulative TE metric for the tree.

In section 3.2 "For this purpose the ingress border node SHOULD try to find a minimum subset of S2L sub-LSPs for which the PathErr needs to be generated towards the ingress node."  This is saying that if a remerge cannot be avoided then two paths should be merged by rejecting the path with the smallest number of leaf nodes and moving all of those leaf nodes onto the other path.  That is maximally conservative of signalling plane resources but the priority is usually to optimize the network.  Say the root of the tree is R and the two merging paths pass through border nodes A and B before merging at node M.  If the cost of path RA + AM is less than the cost of path RB + BM then the network is optimized by moving leaf nodes onto the path through A, irrespective of how many leaf nodes you are moving.  The costs of AM and BM are known to node M from its TE database; the costs of RA and RB could be signalled to node M.

3. Minor / editorial comments
Section 1 para 5 "when P2MP LSP spans" -> "when the P2MP LSP spans"
Section 1 para 6 "However this can lead to a deadlock..." - I couldn't follow the example given, please could you explain or add a reference?
Section 1 para 8 "individual the destinatyions" - typo
Section 1 para 8 "it can lead to data duplication inside the backbone" - how?
Section 1.1 para 4 "entire or part" -> "all or part"
Section 1.1 para 4 "by expanding EROs in Path messages of the destinations" - doesn't make sense
Section 1.1 para 4 "Border node does not know" -> "The border node does not know"
Section 1.1 para 4 "Signaling extension and procedure" -> "Signaling extensions and procedures"
Section 1.2 para 2 "do not guarantee" -> "does not guarantee"
Section 3.2 para 3 "that has less number of" -> "that has the fewest"
Section 3.2 para 3 "These are the S2L sub-LSPs on an incoming interface that has less number of S2L sub-LSPs compared to the second incoming interface that is causing the re-merge condition." - I don't understand this sentence
Section 3.2 para 9 "in history table" -> "in a history table"
Section 3.2 para 9 "until local timer expires" -> "until a local timer expires"
Section 4.3 para 1 "operator may have disabled" -> "the operator has disabled"
Section 4.3 para 1 "the  the" - typo.