Subject: Gen-ART review of draft-ietf-mpls-tp-p2mp-framework-05

From: Russ Housley <[email-masked]>
Date: Fri, 3 Jan 2014 12:30:45 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mpls-tp-p2mp-framework-05
Reviewer: Russ Housley
Review Date: 2014-01-02
IETF LC End Date: 2014-01-16
IESG Telechat date: Unknown

Summary:  Ready for publication.

Question:

Should this document be an update to the MPLS-TP Framework (RFC 5921)?
I am not sure.  RFC 5921 does make it clear that it covers only point-
to-point transport paths.  The answer may be further complicated by
the fact that RFC 5921 is joint work with the ITU-T.

Major Concerns:  None.

Minor Concerns:  None.

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 ...

Please add TE-LSP to the terms defined in Section 1.2.

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.

The phrase "MPLS Transport Profile" appears many places, and it would
be easier if they were replaces with "MPLS-TP" for consistency.

---

From: Loa Andersson <[email-masked]>
Date: Sat, 04 Jan 2014 20:32:07 +0800

Russ,

I never thought about this as an update to RFC 5921. If we publish
this document as is, every syllable of RFC 5921 remains unchanged.

This is hardly an update.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 4 Jan 2014 13:28:20 -0000

Hi Russ,

Thanks for the review.

> the fact that RFC 5921 is joint work with the ITU-T.

I don't think so.
That is, it is perfectly acceptable to build a P2P MPLS-TP system and that
system could be built on protocol solutions that do not include P2MP support.

As you say, 5921 explicitly says:

   This document defines the subset of the MPLS-TP applicable in general
   and to point-to-point transport paths.  The remaining subset,
   applicable specifically to point-to-multipoint transport paths, is
   outside the scope of this document.

...so an "updates" relationship would render this statement doubtful.

I'm pretty comfortable with the documents being separate.

>    The Multiprotocol Label Switching Transport Profile (MPLS-TP) is ...

Sure.

> Please add TE-LSP to the terms defined in Section 1.2.

Sure.

> commas need to be removed.

Yes, you're right. And a minor rewrite could make this even clearer.

> be easier if they were replaces with "MPLS-TP" for consistency.

OK

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Jan 2014 18:41:28 -0500

Russ/Adrian,

A couple of editorial points:

> Thanks for the review.

Agreed!

...

>> Please add TE-LSP to the terms defined in Section 1.2.
Actually, this is a good catch as it really should say: "Traffic
Engineered P2MP LSP" and "Traffic Engineered multipoint-to-multipoint LSPs".

> 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.

Sure.

> OK

We'll have a version ready to go soon and will coordinate with Adrian on
publication.

Thanks again,
Lou