Russ/Adrian, A couple of editorial points: On 1/4/2014 8:28 AM, Adrian Farrel wrote: > Hi Russ, > > Thanks for the review. Agreed! > ... > >> Other Comments: >> >> In the first sentence of Section 1, please define MPLS-TP as follows: >> OLD: >> The Multiprotocol Label Switching Transport Profile is the ... >> NEW: >> The Multiprotocol Label Switching Transport Profile (MPLS-TP) is ... > > Sure. > >> Please add TE-LSP to the terms defined in Section 1.2. > > Sure. Actually, this is a good catch as it really should say: "Traffic Engineered P2MP LSP" and "Traffic Engineered multipoint-to-multipoint LSPs". > >> In Section 5.1, I cannot understand this sentence: >>> >>> Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS >>> recovery, [RFC4872] and [RFC4873], do not explicitly cover their >>> interactions. >>> >> I think that the references are getting in the way. I think the >> message is: "the definitions of P2MP and GMPLS recovery do not >> explicitly cover their interactions." If I am correct, then some >> commas need to be removed. > > Yes, you're right. And a minor rewrite could make this even clearer. > How about: [RFC6373] notes that recovery techniques for Traffic Engineered P2MP LSPs are not formally defined, and such that a definition is needed. A formal definition will be based on existing RFCs and may not require any new protocol mechanisms but, nonetheless, should be documented. GMPLS recovery is defined in [RFC4872] and [RFC4873]. Protection of P2MP LSPs is also discussed in [RFC6372] Section 4.7.3. >> The phrase "MPLS Transport Profile" appears many places, and it would >> be easier if they were replaces with "MPLS-TP" for consistency. > Sure. > OK We'll have a version ready to go soon and will coordinate with Adrian on publication. Thanks again, Lou