Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment
draft-ietf-pce-wson-routing-wavelength-15

[Ballot comment]
I have been on record as saying that publishing these "requirements documents"
as RFCs is bad practice.  They serve no purpose as standalone documents.
Requirements are living entities until the protocol specification that
satisfies them is published.  I would rather see these maintained in a wiki or
living I-D and either not published or published as an appendix to the
corresponding protocol specification.

That being said, I will not stand in the way of this document.

[Ballot comment]
Just a couple of very small things:

-- Section 1 --

  Two lightpaths that share a common fiber link cannot be
  assigned the same wavelength. To do otherwise would result in both
  signals interfering with each other.

I think you mean "To do so", rather than "To do otherwise".

-- Section 3.6 --

    A response SHOULD follow the requestor
    preference unless it conflicts with operator's policy.

I find myself wondering whether this really means "MUST foloow the requestor preference unless...".  Are there other reasons it might be acceptable not to follow the requestor preference?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pce-wson-routing-wavelength-14, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PCEP Requirements for WSON Routing and Wavelength Assignment) to Informational RFC


The IESG has received a request from the Path Computation Element WG
(pce) to consider the following document:
- 'PCEP Requirements for WSON Routing and Wavelength Assignment'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This memo provides application-specific requirements for the Path
  Computation Element communication Protocol (PCEP) for the support of
  Wavelength Switched Optical Networks (WSON). Lightpath provisioning
  in WSONs requires a routing and wavelength assignment (RWA) process.
  From a path computation perspective, wavelength assignment is the
  process of determining which wavelength can be used on each hop of a
  path and forms an additional routing constraint to optical light
  path computation. Requirements for PCEP extensions in support of
  optical impairments will be addressed in a separate document.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pce-wson-routing-wavelength/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1400/

AD Review
======

Hi authors,

I have done my usual AD review of your document in response to the
publication request from the working group. The purpose of my review is
to iron out any issues in the document and make sure I can support it
through IETF last call and IESG evaluation.

Many of my comments below are editorial, but a lot of them are questions
of clarification or intended function. I would like to discuss these
with you and the working group before update the draft.

Thanks for the work,
Adrian

===

Abstract
  Requirements for optical impairments will be
  addressed in a separate document.
I guess you mean
  Requirements for PCEP extensions in support of optical impairments
  will be addressed in a separate document.

---

A couple of abbreviations are used without expansion...
WA
DWA

I think an intro para in section 2 to break out the terminology of
R, WA, and DWA

---

3.1
  A PCEP request MUST include the path computation type.

I don't understand how a PCC knows whether it needs to know the
wavelength or not. Suppose the PCC is an ingress: how does it know
whether the network comprises all nodes that cannot perform wavelength
conversion, all nodes with limited wavelength conversion, all nodes
with full wavelength conversion abilities, or some mixture.  In the
case of the mixture, the choice of path will determine whether the
wavelength must be known or not.

In fact, isn't it the PCE that knows whether or not to supply the
wavelength based on its knowledge of the network capabilities and
possibly based on the path it chose? The PCC, on the other hand, is
always happy to have the labels supplied in the ERO, or not.

Furthermore, depending on the hops in the selected path, the wavelength
assignment may come from the PCE for some hops (path segments) and may
be distributed for other hops. It doesn't seem to be as black and white
in the dimensions you have painted, but I would suggest that this does
not matter because you can push the whole problem to PCE without PCC
having to make any choice.

---

3.2
  (i)    Explicit Label Control (ELC) [RFC4003]

Is this the right reference? It doesn't look like it to me!
ELC is section 5 of RFC 3473.

---

3.2
  (ii)  A set of recommended labels. The PCC can select the
          label based on local policy.

Are you talking about a set of suggested labels for each hop?
Or a set of potential e2e labels to use (from which the PCC
can select just one to use)?

---

3.2
  (c)  In the case where a valid path is not found, the response MUST
      include why the path is not found (e.g., no path, wavelength not
      found, optical quality check failed, etc.)

There is no explanation of "optical quality check" in this document.

I am concerned that "no path found" and "wavelength not found" are
artefacts of the implementation of RWA. Certainly, in the case of R+WA
you might fail to find a path before asking for a wavelength, but even
in that case, can you be sure that there is no path available because
the network is disconnected or because all of the bandwidth (i.e. all
of the labels) on some of the links has been used? In that case, how
can you choose between "no path" and "no wavelength"?

In more general cases, the failure to compute a path is simply the
failure to find a path that meets the constraints. This sort of failure
is no different to the general PCE computation failures - you can't
simply state which single constraint caused the computation failure even
if you know that relaxing one of the constraints would have allowed you
to find a path because relaxing some other constraint(s) might also have
resulted in a path being found.

But anyway, how do you anticipate a PCC will react differently to these
two different return codes? Can a PCC do anything different in the two
cases? Can it vary the request? Can it trigger something in the network?

---

3.3

For consistency with the terminology in 5440, shouldn't you use
"synchronized" instead of "simultaneous"?

---

3.3

  (a)  A PCEP request MUST be able to specify an option for bulk RWA
      path request. Bulk path request is an ability to request a number
      of simultaneous RWA path requests.

Are you adding a requirement here, or are you saying that any solution
must not break existing function? If the latter, why are you singling
out this specific function as being special to not break?

  (b)  The PCEP response MUST include the path and the assigned
      wavelength assigned for each RWA path request specified in the
      original bulk request.

Are you changing SVEC behavior here? Are you making any change to
5440 and 6007?

---

3.4
  2. The corresponding response to the re-optimized request MUST
      provide the re-optimized path and wavelengths.

I think you should add:

  ...even when the request asked for the path or the wavelength to
  remain unchanged.

---

3.4
  3. In case that the path is not found, the response MUST include why
      the path is not found (e.g., no path, wavelength not found, both
      path and wavelength not found, etc.)

Interesting. Not only do my comments from 3.2 (c) apply, but I have to
wonder what it means to be unable to find a path during reoptimization.
Isn't the current path always a legitimate reply to a reoptimization
request?                                                                                                     

---

3.5
  or an
  policy-based restriction

s/an/a/

---

Your use of RFC 2119 words is somewhat inconsistent. Sometimes you are
setting expectations for the protocol solution

  Section 3.6
  A request for two or more paths MUST be able to include an option

and sometimes you are saying what an implementation might do
 
  Section 3.5
  For any RWA computation type request, the requester (PCC) MAY
  specify a restriction on the wavelengths to be used

While I can derive a protocol requirement from the second type of usage
of 2119 language, I think I end up with something ambiguous. For
example, in the quoted text it is possible to interpret:

  - The solution MUST allow the requester to specify a restriction
  or
  - The solution MAY allow the requester to specify a restriction

I think you need to be clearer.

---

s/requestor/requester/

---

3.6
  In a network with wavelength conversion capabilities (e.g. sparse 3R
  regenerators), a request SHOULD be able to indicate whether a
  single, continuous wavelength should be allocated or not. In other
  words, the requesting PCC SHOULD be able to specify the precedence
  of wavelength continuity even if wavelength conversion is available.

I don't object to the PCC being able to have input on this issue, but
it isn't clear to me how the PCC is about to know about the network in
this way.

---

3.7

I believe this requirement, but not how it is worded. Isn't the actual
requirement to allow the PCC to specify the signal type at source, at
destination, and state whether transit modification is acceptable?

Maybe this section is also lacking a little background information?

---

4.6

  Mechanisms defined in this document do not imply any new network
  operation requirements in addition to those already listed in
  section 8.6 of [RFC5440].

Are you sure? Are there no assumptions about the distribution of
wavelength availability information, and wavelength conversion ability,
etc.?

--

I think you have an excess of boilerplate at the end of your draft.
You can safely  delete everything after the Authors' Addresses. (I
suspect your Word template thing is out of date.)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
-> Informational
Why is this the proper type of RFC?
-> Requirement I-D
Is this type of RFC indicated in the title page header?
-> Yes

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This memo provides application-specific requirements for the Path
  Computation Element communication Protocol (PCEP) for the support of
  Wavelength Switched Optical Networks (WSON). Lightpath provisioning
  in WSONs requires a routing and wavelength assignment (RWA) process.
  From a path computation perspective, wavelength assignment is the
  process of determining which wavelength can be used on each hop of a
  path and forms an additional routing constraint to optical light
  path computation. Requirements for optical impairments will be
  addressed in a separate document.

Working Group Summary

  Was there anything in WG process that is worth noting?
-> Linked to I-Ds in CCAMP
  For example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
-> No

Document Quality

  Are there existing implementations of the protocol?
-> N/a (a solution I-D is ready)
  Have a significant number of vendors indicated their plan to
  implement the specification?
-> N/a
  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
-> Cyril Margaria & Ramon Casllas did useful LC reviews
  If there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)?
-> N/a
  In the case of a Media Type review, on what date was the request posted?
-> N/a

Personnel

  Who is the Document Shepherd?
-> Julien Meuric
  Who is the Responsible Area Director?
-> Adrian Farrel

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
-> Looks ready for publication

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 
-> No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
-> No

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
-> N/a

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
-> Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
-> Yes (already discussed in CCAMP)

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?
-> Concurrence of a few individuals, with others being silent

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
-> No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
-> Tomonori Takeda's address needs to be updated

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
-> N/a

(13) Have all references within this document been identified as
either normative or informative?
-> Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
-> No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
-> No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
-> No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
-> N/a
Confirm that any referenced IANA registries have been clearly
identified.
-> N/a
Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
-> N/a

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
-> N/a

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
-> N/a