[mpls] MPLS-RT review on draft-dj-mpls-tp-exer-psc-01

[<[e-mail]>]

Hi, authors and chairs.

I've reviewed draft-dj-mpls-tp-exer-psc-01 as the MPLS-RT process.

a. Is the document coherent?
It's close to coherent. I noticed an inconsistency between section 2.5. and 2.8.
According to section 2.5, FPath and Path values are set to the same as the request 
that EXER replaces. On the other hand, according to section 2.8, these values are 
set as follows.
      E::L  EXER(0,0)for revertive, or EXER(0,1)for non-revertive
      E::R  RR(0,0) for revertive, or RR(0,1) for non-revertive
I suppose the description in section 2.5. is the intended action.
For example, when the state moves from N to E::L, Path value in EXER will be 0.

b. Is it useful (ie, is it likely to be actually useful in operational networks)?
I suppose it's useful, considering that traditional transport protection protocol 
(i.e. APS) has the same mechanism, and an operator is involved in the authors list.

I have one comment.
Taking into account the objective, the management system should be notified 
when a node receives remote RR or EXER requests. 
It will be valuable if the authors address this point in the draft, 
for example in section 2.3.

c. Is the document technically sound?
I have one question to section 2.7.3. and 2.8.
According to these sections, when the current state is E::L and the configuration 
is non-revertive, a local Clear command causes a state transition to DNR 
even if user traffic is transmitted on working path. As a result, the traffic 
will be switched from working path to protection path. Is this the intended action?

In my understanding, the state should go into N in this case, according to section 1, 
"without triggering the actual traffic switching".
Dividing state E::L into two states, E::L(working selected), and E::L(protection selected), 
might clear this point.

d. Is the document ready to be considered for WG adoption?
I hope the comments above are closed before WG adoption.

Best Regards,
Kenji.