Subject: [mpls] MPLS-RT comments on draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-08

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 25 Jul 2012 15:48:16 +0000

These are my review team comments on draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-08.  

* Is the document coherent?
 
It needs work.  The formatting is off (try to print the pdf version of the txt doc and you'll see what I mean).  It needs a serious editorial cleanup - for example, section 4.1/4.2 refer to a flag as both Recording and Recording Request, and another as Re-merge Presence and Re-merge Present.  It also has a structure that makes it hard to follow, and a large number of SHOULDs where I think there ought to be MUSTs.

* Is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?  

I believe that this document solves the problem it purports to solve.  It does so largely by adding three bits and an error code to extend existing p2mp single-area procedures across domain boundaries.  I think at its heart it is technically sound, although its current state makes it hard to follow.

* Is the document ready to be considered for WG adoption?

There are three parts to this question: technical suitability, document quality, and desirability.

The document seems technically suitable; the procedures it defines are a good start to solving the problem, and that's what a document needs to be before WG status.

As I said above, the quality is not quite there.

As far as desirabilty...I have reviewed v08 of the document.  v00 was posted in July of 2008, so the doc is quite old.  Although I buy into the general idea that things which work in a single domain should work across domains, I'd like to see whether this document has interest from others, primarily operators.  

eric

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 30 Jul 2012 21:00:08 -0400

Dear All,
Please find my MPLS-RT comments on draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-08 below:

*       Is the document coherent?
I found that terminology and identification for Re-merge Recording Request flag need improvement. At least once the flag seem to be referred as Re-merge Recording Flag. And several versions of capitalization and use of quotation marks appear throughout the document.
Document can benefit from tightening up and stricter use of RFC 2119 terms in sections 4.3 Signaling Procedure and 5.0 Reoptimization Signaling Procedure. E.g. the last sentence of second paragraph in Section 4.3 "In this case, before the Resv message is sent to the upstream node, the node adds the RRO Attributes sub-object to the RRO and sets the "P2MP-TE Re-merge Recording Request" Flag" not clear whether operations are MUST, SHOULD or merely CAN. I can suggest more similar places on- or off-line.
Then there's reference to path error 25 which, as I understand, Notify Error defined in RFC 3209.

*       Is it useful?
Document proposes solution to realistic, protocol-wise, scenarios. Though without confirmation from network operator community it is rather difficult to conclude how real scenarios are and how helpful the proposed solution.

*       Is it technically sound?
As mentioned in the first bullet, normative language in sections 4.3 and 5 needs to be more definite.
Another technical aspect of proposed solution - generality. It might be beneficial to look for solution of described scenarios as part of GMPLS, not only as MPLS-TE.

*       Is the document ready to be considered for WG adoption?
I think that input from network operators is needed.

Regards,
        Greg