Re: [Pce] Shepherd's review of draft-ietf-pce-inter-area-as-applicability-06

[Quintin zhao <[e-mail]>]

Hi Jon, 

Great, a good review! This is really helpful. Will finalize the document based on your comments, and most recent updates from Dhruv. Our plan is to submit the new version very quickly. We will find someone to perform a final English review as you suggest. 

Thanks!
Quintin, and authors.


------------------------------

Message: 2
Date: Tue, 7 Mar 2017 17:27:43 +0000
From: Jonathan Hardwick <[e-mail]>
To: "[e-mail]"
	<[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [Pce] Shepherd's review of
	draft-ietf-pce-inter-area-as-applicability-06
Message-ID:
	<[e-mail]>
	
Content-Type: text/plain; charset="us-ascii"

Hello

I am shepherding this draft, which has passed working group last call and is in the queue for sending to the IESG.  I have reviewed it to determine whether it really is ready to be submitted to the IESG.  This draft is an important piece of work for the PCE working group and I would like to thank the authors for all their work on it so far, but unfortunately I don't think it is ready for publication yet.  Probably the biggest impediment to getting drafts through the IESG is when the drafts lack clarity, and I feel that more clarity needs to be brought to this draft before we take it forward.

My comments are below.

Best regards
Jon


General Comments
This document does an important job in explaining how PCEs can best be used to solve problems in inter-domain path computation.  It is thorough and covers all the appropriate areas.

The document seems repetitive and a bit bloated by text that is not really relevant to the main purpose of the doc.  Some parts of the text feel redundant (I have pointed them out explicitly below).  Other parts of the text repeat statements that have already been made, or else just repeat information from other documents.  I have pointed out as many examples of this as I can below but I would like the authors to review their text themselves and try to remove the redundant bits of text.

Some sections of this document waffle without making a clear point about inter-domain path computation.  I've made specific comments below about passages that I feel lack a clear point.  But please could the authors review their own text?  The document needs to succinctly describe problems in inter-domain path computation and point out the ways a PCE can help solve them.  If there are any parts of this document that do not fulfil that brief, please consider removing them.

Some sections of the document need to be reviewed by an English speaker for grammar and clarity.  I made quite a few comments below to clarify sentences and improve the grammar, but I ran out of steam at around section 6.  Please could one of the English speaking authors finish off the job?

 
Section 1
s/remotely initiated PCE, deployment scenarios/remotely initiated PCE deployment scenarios/
s/it maybe necessary/it may be necessary/
" Once a path computation request is received, the PCC will send a request to the PCE. "  Sentence feels redundant.
s/The PCE discovery mechanism [...] allow/The PCE discovery mechanism [...] allows/
s/An Objective Function [...] specify the/An Objective Function [...] specifies the/
Section 1.6, I don't think you need to list all the OFs in RFC 5541, there's nothing special about them.

Section 3
s/administered by separate Service Providers, it would break/administered by separate Service Providers.  It would break/
s/ different Service Providers. Then cooperating PCEs/ different Service Providers, then cooperating PCEs/
s/ it can supply this information/ it can supply the destination domain/
s/egress domain/destination domain/

Section 4
Please define " simply-connected " or expand the term.  I think you mean "connected in a simple path with no branches and single links between all domains".
Section 4.2 text duplicates the text in section 3.1 1st paragraph. Please delete one of them.
s/ are composed by/ are composed of/
s/ are usually interconnected between them/ are usually interconnected/

OLD
A typical node degree ranges from 3 to 10 (4-5 is quite common), being the node degree the number of neighbors per node.
NEW
The node degree (the number of neighbors per node) typically ranges from 3 to 10 (4-5 is quite common).

Second paragraph of 4.3 "Networks are sometimes..." is redundant.  It has all been said already.
s/ Whenever an specific/ Whenever a specific/

Section 4.4 Again it feels like all of this has been said in section 3.1 already, except the bit about SRLGs.  I suggest combining these bits of text.  Perhaps section 3.1 should be removed.

Section 4.5 "A non-comprehensive list" Is it important to give this list?  It seems to add nothing to the existing reference to RFC5540/6007 - suggest removing it.

s/ reach the destination domain, a domain sequence/ reach the destination domain.  A domain sequence/
s/ is defined in [RFC3209], [RFC7897] specifies new/ is defined in [RFC3209].  [RFC7897] specifies new/

Section 5
5.1.1 " [RFC5441] provides a more optimal method to specify inclusion or exclusion of an ABR" - this is the BRPC RFC.  It computes a more optimal path in general.  But please can you clarify how it optimizes " inclusion or exclusion of an ABR "?
s/ an area must be include or exclude from/ an area must be included or excluded from/
s/ the indication of if a strict/ the indication of whether a strict/
s/ to compute diverse across/ to compute diverse paths across/
5.1.3 What point are you making by listing these types of diversity? 

Section 5.2 - I don't understand what point this section is making.  I think it says that an operator may know an intra-area path exists, but then requests an inter-area path anyway, but then looks at the response and says "I don't like some of those areas" and so uses the intra-area path instead.  Really?  I would have thought that they would just use the intra-area path in the first place.  Also this section seems to imply that the PCE provides the area / AS IDs in the returned ERO, which I do not believe is the case.

Section 6
There are several mistakes in English in this section.  I started listing them but ran out of time.  Please have an English speaker review and overhaul it.
6.1.1 I can't tell what this section is trying to say.  Please make the point clearly.

Section 7
Ditto - many English mistakes in this section.
All the text in the first part of section 7 (before 7.1 starts) is redundant, i.e. has been said already.  Please take it out.
7.1 " It could be helpful " ... this is too wishy-washy.  Helpful under what circumstances?
" the TED must be populated. Inter-as connectivity information may be populated "  I think you mean MUST and MAY.  This sentence is in the passive voice which makes it hard to understand which entity must take the described action.  I.e. which entity populates that TED?
7.1 This section is unclear.  What point is it trying to make?  I think I can see two points in the text, but they are entangled and obscure.  The first point is that the TED may be provided by a variety of sources.  The second point is that, when the IGPs provide the TED, they do not provide information on inter-AS TE and therefore this information must come from another source.  Please separate your points and make them clearly.

7.1.1 " As PCE algorithms rely on information contained in the TED " - redundant, delete.
7.1.1 Final paragraph - as these LSPs are static, why can't they be provisioned statically in the TED?

What happened to section 7.2?

7.3 " The management based solutions could also be used in conjunction with the BRPC algorithm."  I think what you are saying here is that BRPC may be used to pre-plan an AS sequence whereas the actual path within domains is not pre-planned and is instead computed using per-domain computation.  Please clarify.
7.3 This section ought to point out that in an inter-domain path, the operators of each domain must agree to what extent paths must be pre-planned and manually controlled.

7.4 What point is this section making?  That has not already been said in RFC 5152?
s/RFC6805]/[RFC6805]

7.5 How is this different to 7.4?  Note that per-domain path computation is also "co-operative PCEs".

7.6 This section just repeats material from RFC 6805 so seems redundant in this document.

Section 8
Most of the introduction repeats points already made by the document and doesn't need to be said again.  The introduction to s8 should say something like this.
NEW 
   This section discusses the techniques that co-operating PCEs
   can use to compute inter-domain paths without each domain
   disclosing sensitive internal topology information (such as
   explicit nodes or links within the domain) to the other domains."

s/allows explicit route information to used/allows explicit route information to be used/

Section 10
s/path that satisfies/paths that satisfy/
I would retire the section heading for 10.1 and just make section 10 one flat section.

Section 11
"Deployment of policy should also consider the need to be sensitive to commercial and reliability  information about domains and the interactions of services crossing  domains."  What does that mean?  i.e. who needs to consider this, what exactly are they considering, what do they do about it, and how does it relate to PCE?

Section 12
Overlaps and duplicates significantly with section 7, especially section 7.1.  Please combine the information in these sections.

Section 13
"section 8.4 of [RFC5440] and will not be repeated here." Is this stray text?  Delete it?

Sections 13.3 and 13.4 appear out of order (they appear after section 14).
Section 13.4 mentions security procedures - this should be done in section 14.
Otherwise, section 13.4 just repeats stuff from RFC 5440 - not necessary.  Please delete it unless there is something specific to say about the inter-AS case.
Section 13.5 Just repeats stuff from RFC 5440 - not necessary.  Please delete it unless there is something specific to say about the inter-AS case.

Section 14
I think this section should also talk about how to establish the trust relationship between domains and how PCEs can authenticate with each other.