Re: [RTG-DIR] 答复: [Pce] RTG Area review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures

[Loa Andersson <[e-mail]>]

Quintin,

Thanks for the updates - rtg-dir reviews are to support the ADs, I let
the ADs decide if more is needed based on my comments.

/Loa

On 2014-05-28 13:26, Quintin zhao wrote:
> Dear Loa,
>
> Thanks for your detailed review for this draft. Please see  our replies
> in-line. We have incorporated your comments into the new version
> attached here. Please let us know if you have further comments.
>
> Quintin
>
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> On Wed, May 14, 2014 at 11:47 AM, Loa Andersson <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review
> is to provide assistance to the Routing ADs. For more information
> about the Routing Directorate,please see
> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> Document: draft-ietf-pce-pcep-inter-domain-p2mp-procedures-06
> Reviewer: Loa Andersson
> Review Date: 2013-05-14
> IETF LC End Date: couldn't find
> Intended Status: Experimental
>
> Summary:
>
> This document is basically ready for publication, but has nits that
> should be considered
>
> prior to publication.
>
> Comments:
> 1. I like that an experimental RFC (for once) actually describe an
>     experiment
>
> 2. The abstract says:
>    "The ability to compute paths for constrained point-to-multipoint
>     (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across
>     multiple domains has been identified as a key requirement for the
>     deployment of P2MP services in MPLS and GMPLS-controlled networks."
>
>     Where was this defined (reference)?
>
> RFC5671 but implicitly (section 3)
>
>
>     3. There are a couple of cases where words that ae in the 2119-language
>         appear in the document in lower cases, please check if this is
>         intended or if the normative language are intended.
>
>     4. For the terminology section it would be good to know which terms
>         that are defined in this document for the first time, otherwise
>         please give a reference to where to find the definition.
>
> We will append terminology section -
>
>     Terminology used in this document is consistent with the related
>
>     MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875],
>
>     [RFC5376], [RFC5440], [RFC5441], [RFC5671] and [RFC5862].
>
>     The additional terms Core-Tree, Leaf Domain, Path Tree, Path Domain
>
>     Sequence, Path Domain Tree, Root Domain, Sub-Tree and Transit/branch
>
>     Domain are further defined below.
>
>
>     5. This is possibly an oxymoron comment, but it seems to me that the
>         problem statement (section 3) is too focused on describing how hard
>         it is to solve the inter-domain P2MP path computation, rather than
>         to describe what the problem are.
>
> Wewill rename the section as *Examination of Existing Mechanisms**.*
>
>
>     6. I'm a little bit concerned about the requirements, it seems that
>         they are very close to design criteria.
>
>     7. Section 7.1 the concept "entry boundary nodes" are used, is this
>         concept defined anywhere? For example from figure 2 I understand
>         that L, W, P and T are entry boundary nodes, while D and E are not.
>
> Entry boundary nodes is defined in 5441 etc.
>
> But we specifically mean entry boundary node of the leaf/destination
> domain and this is L,W,P & T and not D & E.
>
>
>     8. I think it would be good have an H-PCE entry in the terminology
>         section.
>
>     The document is fairly easy to read and quality is good, there is
>     sometimes a wish from the authors to bring through how dammed hard this
>     problem is to solve - they might be right - but there is a risk of
>     creating a lot of trees that stops you from seeing the forrest (or
>     maybe the other way around).
>
>     Major Issues:
>
>     None
>
>     Minor issues:
>
>     It seems that the document should lead up to a set of protocol
>     extensions, but in the the only change is to add the C-bit, right?
>
> On the wire changes (message and object encoding) is limited.
>
> There are necessary procedure changes.
>
>
>     Nits:
>
>     None - that are not captured in the comments above!
>
>
>     /Loa
>
>     --
>
>
>     Loa Andersson                        email: [e-mail]
>     <mailto:[e-mail]>
>     Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>     Huawei Technologies (consultant)     phone: [phone]
>
>     _______________________________________________
>     Pce mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/pce
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]