Subject: Re: [Pce] FW: FW: I-D Action: draft-ietf-pce-wson-routing-wavelength-11.txt

From: Leeyoung <[email-masked]>
Date: Mon, 14 Apr 2014 21:31:36 +0000

Hi Cyril,

Thanks for your comment. I will reflect the two changes in the next revision. Please see in-line for my comment.

Regards,
Young

From: Cyril Margaria [mailto:[email-masked]]
Sent: Monday, April 14, 2014 3:48 PM
To: Leeyoung
Subject: Re: FW: FW: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-11.txt

Hi,
I had time to review the changes, there are two changes that you accepted, but is not reflected into the document.

Hi PCErs,

I have a few comments on the document:

Section 1.1 : Strange indentation

YOUNG>> I will look into that.

Cyril>>> Done

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

YOUNG>> I will look into that.

Cyril>>> Done

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.

YOUNG>>  PCE discovery is not a requirement, but can be considered as an option. What is OPEN extension? I can add if you want the reference info in Section 3.5. In WSON environment, RWA-capable PCE discovery can be configured instead of depending on discovery mechanisms, IMHO.

Cyril>>> the new text is OK

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.

YOUNG>> Agree. Will change.
Cyril>>> Done

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

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

YOUNG>> Not sure what the mixed bulk requests achieve. GCO [RFC 5557] addresses the bulk request for R.

Cyril>>> Done

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.

YOUNG>>  accepted.

Cyril>>> Not done?

YOUNG>> This was done in a little different wording. Please see Section 3.5 where

3.5.  Wavelength Range Constraint

   For any RWA computation type request, the requester (PCC) MAY
   specify a restriction on the wavelengths to be used.

YOUNG>> The reason for “MUST -> MAY” is that this is an optional requirement rather than mandatory. (This was actually per Ramon’s comment, which I think I agreed with him)

I will add the following clause, “The requester MAY use this option to restrict the assigned wavelength 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.

YOUNG>>  How about the following:

Note that the requestor (e.g., PCC) 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.

Cyril>>> The proposal is OK, but not applied to version -11

YOUNG>> Agree. I will correct.

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

YOUNG>> Yes.

Cyril>>> new text is OK

The section could be renamed "Wavelength assignement policy constraints"

YOUNG>> Good suggestion, Will change.

Cyril>>> new text is different, new text is OK

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

YOUNG>> In Section 2.1.1, req 2 will refer to Section 2.1.5 for this requirement.

Cyril>>> New text is OK

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.

YOUNG>>

NEW:

  A request for 2 or more path (e.g., 1+1 link disjoint paths) MUST be able to specify an option constraining the path to have the same wavelength(s) assigned.

Cyril>>> OK, new test is OK

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

YOUNG>> I put as an example in the above suggestion.

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

NEW
      o OIC list

YOUNG>> I think OIC is a solution for signal compatibility for FEC and Modulation. As a requirement, I think the current text is fine.

Cyril>>> OK

--

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

YOUNG>> Agree, as a solution, but not as a requirement.

Cyril>>> OK

On 18 March 2014 18:58, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Cyril, have a safe trip!

Young

From: Cyril Margaria [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 18, 2014 5:58 PM
To: Leeyoung
Subject: Re: FW: FW: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-11.txt

I will try to do it soon (After changing companies, I am changing continents), I had a look to your resolution proposal, they looked all fine, I just need to do a pass and I will respond to the ML.

On 18 March 2014 21:33, Leeyoung <[email-masked]<mailto:[email-masked]>> wrote:
Hi Cyril,

Would you be able to comment on the new update on PCE WSON draft?

Ramon has cleared on the update. Thanks.

Young

-----Original Message-----
From: Ramon Casellas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 13, 2014 12:49 PM
To: Leeyoung; Cyril Margaria
Cc: Julien Meuric
Subject: Re: FW: [Pce] I-D Action: draft-ietf-pce-wson-routing-wavelength-11.txt

El 12/03/2014 2:09, Leeyoung escribió:
> Hi Ramon and Cyril,
>
> Thanks for providing valuable comments that improved clarity and readability of the draft.
> Let me know if this update is good to go or still needs further refinements.
>
>
I am ok with the changes, I guess some of the confusion came from the strange indentation and selection of titles R.

--
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division Optical Networks and Systems Department -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya Parc Mediterrani de la Tecnologia (PMT) - Edifici B4 Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168<tel:%2B34%2093%20645%2029%2000%20ext%202168>-- Fax. +34 93 645 29 01<tel:%2B34%2093%20645%2029%2001>