[mpls] MPLS-RT review of draft-wijnands-mpls-mldp-node-protection-02 and of draft-zhao-mpls-mldp-protections-03

[Martin Vigoureux <[e-mail]>]

Hello,

I have reviewed draft-wijnands-mpls-mldp-node-protection-02 and 
draft-zhao-mpls-mldp-protections-03

Relating to the specific question asked to the reviewers:
The documents describe two different ways of achieving the same useful 
thing (mLDP node protection).
* I do not think the two documents should be merged
* draft-wijnands-mpls-mldp-node-protection-02 is more ready to be 
progressed as WG document than draft-zhao-mpls-mldp-protections-03 is.
* If both documents were to be progressed as WG documents, an 
applicability document providing for example information on the 
situations in which a solution is more desirable than the other, if 
relevant, and/or a discussion on the scalability of the approaches, 
and/or on the capability to effectively find disjoint paths in such 
contexts, and/or on the use of such mechanism(s) in conjunction with 
other protection mechanisms, ..., might be valuable for those wishing to 
deploy such technology/ies. Note that the last two points are relevant 
even if a single document is progressed.

Please see below my observations for the two documents.

-m

---
draft-wijnands-mpls-mldp-node-protection-02
General
* well written and quite concise but at the expense of a perfectly clear 
description of the procedures which would thus benefit from extra 
clarification
* the document is coherent, useful and technically sound, yet it could 
benefit from a discussion on the scalability of the proposed solution 
especially with regards to the t-ldp sessions.
* the document is ready to be considered for WG adoption.
* Some "must" might need to be capitalized


Section 2.2
s/N's/N/

          In order to protect node N, all the members of the MP2MP must
    participate in protecting node N by acting both as PLR and MPT LSR.

Is it really all the members of the MP2MP LSP or only the LDP peers of 
the root?
Confusion can come from the fact that figure 2 shows a very simple MP2MP 
LSP where all members of the LSP are also directly-connected-to-N members


Section 2.3
s/If the PLR address on N changes for a give MP LSP/If the PLR address 
on N changes for a given MP LSP/


Section 3
s/the PLR would have assign a Label Mapping/the PLR would have assigned 
a Label Mapping/


Section 4 and Section 5
These sections need a bit more work to clarify the procedures and 
sequence of events, so as to lift potential misunderstandings.

With regards to the reachability of N. Beginning of Section 4 the text says:
                     When LSR1 discovered that node N is unreachable, it
    can't determine whether it is the 'LSR1 - N' link or node N that
    failed.
but first paragraph of Section 5 says:
                                        The procedures following are
    depending on whether the link 'LSR1 - N' has failed or node N itself.
The two pieces of text seem contradictory. Information should be given 
on how (and when?) the distinction could be made.

Also, with regards to the reachability of N, it should be clarified if 
it is only considered through the 'LSR1 - N' link or not.

Also, the two following sentences seem to contradict each other:
                                                    If only the link
    failed, LSR2 and LSR3 will receive duplicate packets due to the two
    protection mechanisms.  To prevent duplicate packets to be forwarded
    to LSR2 and LSR3, either the primary upstream LSRs or the secondary
    upstream LSRs should be forwarding MPLS packets, but never both at
    the same time.
The first one says that duplicate packets will be received while the 
second says that duplicate packets should not be received.
Strictly speaking it seems that duplicate packets will be received by 
LSR2 and LSR3 but be dropped and that it will be the case until label is 
withdrawn, and from that point on no duplicate traffic will be received.

Also, in Section 4 the use of forwarding is somehow misleading. Indeed, 
rather than which primary or secondary LSR forwards the packets, the 
point seems to be more about which primary or secondary LSR do the MPTs 
decide to receive traffic from.


Section 5.1 and 5.2
Similarly to a previous remark, it appears that LSR2 and LSR3 need to be 
able to make a distinction between 'LSR1 - N' link failure and node N 
failure. While I understand that both the capability to detect that N is 
unreachable and the capability to make a distinction between the two 
types of failures is outside of the scope of the document, I believe 
that the described procedures strongly depends on this capability.
If so, I would suggest to add somewhere something like "It MUST be 
possible to distinguish 'LSR1 - N' link failure from node N failure".

One could wonder why Section 5.1 and 5.2 are not in Section 4.


Section 5.2
If N is still reachable why does LSR1 invoke the node protection mechanism?
More generally, the procedures described in the document are based on 
the fact that both protection mechanisms are invoked while Section 4 
states that is is only a MAY.


Section 5.3
                                          LSR1 will find that M is its
    new primary upstream LSR to reach the Root and LSR3 will find Q.

I guess what was meant is:
                                          LSR2 will find that P is its
    new primary upstream LSR to reach the Root and LSR3 will find Q.

Also I tend to think that M should be switched to P in:
                                       As soon as the new primary
    upstream LSRs M and Q are activated,


Section 10.1
Update reference for draft-napierala-mpls-targeted-mldp
---


---
draft-zhao-mpls-mldp-protections-03
* The document substantially lacks coherency and clarity. It seems that 
the intent was to be exhaustive in the cases/options covered but this is 
at the expense of readability/understandability.

* Also, and more importantly, there are indications that parts of the 
solution are still incomplete from a design perspective (qualified as 
"TBD" or requiring further research, e.g., Section 4.2, 4.3.1, 5.).

* Also, while the discussion on disjointness is in principle interesting 
and valuable, the way it is currently covered in the document 
participates to making it hard to read.

* The document would also benefit from resolving a good number of 
phrasing/wording/editorial issues.

As such, I do not think the document is ready to be considered for WG 
adoption.
A substantial revision seems necessary before being able to 
appropriately assess the document.
---