Subject: [Pce] WG Last Call of draft-ietf-pce-wson-routing-wavelength-10

From: Julien Meuric <[email-masked]>
Date: Mon, 03 Feb 2014 18:03:34 +0100

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).

Thanks,

JP & Julien

---

From: Julien Meuric <[email-masked]>
Date: Tue, 18 Feb 2014 17:28:21 +0100

Hi all.

This last call has ended. We have not seen many reviews. The chairs' 
will come soon.

JP & Julien

Feb. 03, 2014 - Julien Meuric:
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 25 Feb 2014 11:13:21 +0100

> 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.

---

From: Cyril Margaria <[email-masked]>
Date: Tue, 25 Feb 2014 14:03:51 +0100

Hi PCErs,

I have a few comments on the document:

Section 1.1 : Strange indentation

indentation:
============
The indentation of the following section is not consistent:

Section 1.1
Section 2.1
Section 2.1.1
Section 3.1
Section 3.2
...

Section 2.1.1
=============

Is there a requierement for RWA-capable PCE discovery?
IGP-based discovery is addressed in section 3.5, but OPEN extension could
also be covered.
A PCC expecting RWA-capable PCE will only be able to detect a non RWA
capable upon request.
It is likely that request are not very frequent in WSON networks, so a
misconfiguration may be discovered quite late.
OPEN extension would allow a faster detection.

Req 2) : I believe ii) is not only for D-RWA, but also covers RWA.
OLD:
     (i) Explicit Label Control (ELC) [RFC4003]

     (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)

NEW:
     (i)  Explicit Label Control (ELC) [RFC4003].

     (ii) Non-Explicit labels in the form of Label Sets. The PCC can select
the label based on local policy.

   Note that option ii) may also be used in R+WA or DWA.

Section 2.1.2
=============

  Is it possible to mix in a bulk request, R and RWA requests?

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.
NEW
   For a RWA request, the request MUST be able to specify an option for
   a restriction on the wavelengths to be used.
   The requester MAY use this option to restrict the assigned wavelenght for
   Explict Label or Label Sets.

--
 This is more in line with the rest of the document. The req being on the
protocol, not involving the PCC is better.

OLD
   Note that the requestor (PCC) is NOT required to furnish any range
   restrictions. This restriction is to be interpreted by the PCE as a
   constraint on the tuning ability of the origination laser
   transmitter.

NEW
   Note that the requestor is NOT required to furnish any range
   restrictions. This restriction may for example come from the tuning
   ability of a laser transmitter, any optical element, or an policy based
restriction.

--
 The PCE should not interpret the restriction, just apply it.

Section 2.1.5
=============

in "The PCReq Message May include specific operator's policy", do you mean
MAY?

The section could be renamed "Wavelength assignement policy constraints"

The explicit label versus Label set could also fit in this section, or
section 2.1.1 req 2 should refer to this section.

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.
NEW
  A request for 2 or more path MUST be able to specify an option
constraining the path to have the same wavelength(s) assigned.

--
 Computing a 1+1 path is one use case, but this may apply for other
protection type. This can be achieved by removing the protection aspect.

Section 2.1.6
=============

NEW
      o OIC list

--

draft-ietf-ccamp-rwa-info-21 defines the concept of OIC, PCEP should be
able to transport the same kind of info

Best regards,
Cyril

On 18 February 2014 17:28, Julien Meuric <[email-masked]> wrote:

> Hi all.
>
> This last call has ended. We have not seen many reviews. The chairs' will
> come soon.
>
> JP & Julien
>
>
>> 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).
>>
>> Thanks,
>>
>> JP & Julien
>>