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 <jonathan.hardw...@metaswitch.com>
To: "draft-ietf-pce-inter-area-as-applicabil...@ietf.org"
<draft-ietf-pce-inter-area-as-applicabil...@ietf.org>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: [Pce] Shepherd's review of
draft-ietf-pce-inter-area-as-applicability-06
Message-ID:
<by2pr0201mb191030b5de7c3a8a3b370b2284...@by2pr0201mb1910.namprd02.prod.outlook.com>
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.
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
