El 03/02/2014 18:03, Julien Meuric escribió:
Hi all.
Since many of you are going to dedicate some time to IETF matters over
the upcoming days, here comes some homework.
This message ignites a 2-week WG last call on
draft-ietf-pce-wson-routing-wavelength-10. It will end on Monday,
February 17, 11:59 PM (UTC-12).
Dear all,
A (late) short, fast review of the document below. Feel free to
accept/discard at your discretion
R.
General Comments:
* In general, requirements are stated in terms of messages (e.g. PCReq and
PCRep) rather than in terms of PCEP requests and responses. IMHO, given that
PCReq messages contain svec lists, lists of requests, etc. I would
suggest the
requirements using the request/response RBNF constructs.
For example:
OLD
The PCReq Message MUST include the path computation type.
NEW
A PCEP request [for a lighpath within a PCReq message] MUST include the
path computation type.
Section 2.1.1
==========================
I would move the first bullet "1" out of 2.1.1 which is focused on RWA.
Requirement "1" is to specify R or RWA
Section 2.1.1 then focuses on RWA
OLD
When the PCReq Message is RWA path computation type, the PCReq Message
MUST further ...
NEW
When the request is a RWA path computation type, the request MUST
further include ...
- (ii) Non-Explicit labels in the form of Label Sets (This will allow
Distributed WA at a node level where each node would select the
wavelength from the Label Sets)
I am not sure of what Non-Explicit implies here. Maybe change to "a set
of recommended labels"...
I am confused here. If the path computation type is RWA, the Distributed
WA does not apply, does it?
A new requirement could be added: is a requirement that when the R path
computation type is selected the PCE MAY provide a Label Set ?
NEW
2.b In case of a R computation type, the response MAY provide
[Non-Explicit ?] labels in the form of Label Sets. This will
allow Distributed WA at a node level where each node would
select the wavelength from the Label Sets.
OLD
3. The PCRep Message MUST include the route, wavelengths assigned to
the route and indication of which wavelength assignment option
has been applied (ELC or Label Sets).
NEW
3. In case of a RWA computation type, the response MUST include the
wavelength(s) assigned to the route and an indication of which
label assignment option has been applied (ELC or Label Sets).
Rationale: the route is implicit by RFC5440
OLD
4. In the case where a valid path is not found, the PCRep Message
MUST include why the path is not found (e.g., no route,
wavelength not found, optical quality check failed, etc.)
NEW
4. In the case where a valid path is not found, the reponse
MUST include why the path is not found (e.g., no route,
wavelength not found, optical quality check failed, etc.)
Section 2.1.2
=============
[Q] Is the possibliity of requesting R bulk requests not a requirement?
or is it assumed that existing mechanisms are enough?
Section 2.1.3
==============
OLD
1. For a re-optimization request, the PCReq Message MUST provide the
path to be re-optimized and include the following options
NEW
1. For a re-optimization request, the request MUST provide both the
route and current wavelength to be re-optimized and MAY include
the following options:
a.
b.
[c is implicit by not including options]
Section 2.1.4
==============
OLD
For any PCReq Message that is associated with a request for
wavelength assignment the requester (PCC) MUST be able to specify a
restriction on the wavelengths to be used.
Note that the requestor (PCC) is NOT required to furnish any range
restrictions.
NEW?
For any RWA computation type request, the requester (PCC) MAY
specify a restriction on the wavelengths to be used.
Rationale: "MUST be able but is NOT required"
Section 2.1.5
===============
OLD
The PCReq Message May include specific operator's policy information
for WA (E.g., random assignment, descending order, ascending order,
etc.)
NEW
A RWA computation type request MAY include the requestor preference
for WA (E.g., random assignment, descending order, ascending order,
etc.). A response SHOULD follow the requestor preference unless
operator's policy.
Rationale: Change wording?
OLD
The PCReq Message SHOULD be able to request, when requesting a 1+1
connection (e.g. link disjoint paths), that both paths use the same
wavelength.
-> It is not clear to me how to request a 1+1 connection. I think this is
an important requirement in itself. In general, what are the
requirements
regarding protection in PCEP? what about other protection types?
OLD
The PCReq Message SHOULD be able to request, when performing 3R,
that wavelength may change or not
NEW
In a network with wavelength conversion capabilities (e.g. sparse
3R regenerators), a request SHOULD be able to indicate whether
a single, contiguous wavelength should be allocated or not. In other
words,
the requesting PCC SHOULD be able to constrain the wavelength
continuity even if wavelength conversion is available.
Rationale: the initial requirement is a bit vague. I am not sure if
the intent of he requirement is that?
Section 2.1.6
===============
OLD
The PCReq Message MUST be able to specify restrictions for signal
compatibility either on the endpoint or any given link. The
following signal processing capability should be supported at a
minimum:
"A request MUST be able to ..."
s/on the endpoint/on the endpoints ?
s/capability/capabilities ?
Notes: Not sure about the "any given link". It may be good to
be more verbose on this requirement. Relationship with IRO?
Section 3
===============
3. Manageability Considerations
Nothing is said regarding session parameters on a PCE:
o Policy regarding WA algorithms: first-fit, random...
o Whether to use Explicit Label Control or not
...
Final comments
===============
- Nothing is said about bidirectional LSPs. It seems that being able to
compute a bi-directional LSP with the additional constraint of having
the same upstream and downtream wavelength would be IMHO a requirement.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
