Subject: [Pce] Alexey Melnikov's No Objection on draft-ietf-pce-wson-rwa-ext-11: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Feb 2019 04:46:09 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-pce-wson-rwa-ext-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Benjamin's DISCUSS is a superset of issues I spotted, so I am agreeing with it.

In Section 4.1:

     . Wavelength Selection TLV (32 bits): See Section 4.2 for
        details.

Is TLV value 32 bit or the whole TLV? (This is the same issue as raised by Benjamin)

In Section 4.3:

   o  Link Identifiers: Identifies each link ID for which restriction
   is applied. The length is dependent on the link format and the Count
   field.

Is the type field extensible?

   See Section 4.3.1. for Link Identifier encoding and Section
   4.3.2. for the Wavelength Restriction Field encoding, respectively.

8.5. New PCEP TLV: Optical Interface Class List TLV

   As described in Section 4.3, a new PCEP TLV is defined to indicate
   the optical interface class list. IANA is to allocate this new TLV
   from the "PCEP TLV Type Indicators" subregistry
   (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
   indicators).

   Value             Description                Reference
   ---------------------------------------------------------
   TBD5              Optical Interface          [This.I-D]
                     Class List

I don't see TBD5 referenced anywhere else in the document.

8.6. New PCEP TLV: Client Signal TLV

   As described in Section 4.3, a new PCEP TLV is defined to indicate
   the client signal information. IANA is to allocate this new TLV from
   the "PCEP TLV Type Indicators" subregistry
   (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-
   indicators).

   Value             Description                Reference
   ---------------------------------------------------------
   TBD6              Client Signal Information  [This.I-D]

I don't see TBD6 referenced anywhere else in the document either.

---

From: Leeyoung <[email-masked]>
Date: Thu, 7 Feb 2019 01:44:20 +0000

Hi Alexey,

Thanks for your comments. Please see in-line for my response to each of your comments. Please let me know if you would have further comments.

Thanks & best regards,

Young

-----Original Message-----

From: Alexey Melnikov [mailto:[email-masked]]

Sent: Tuesday, February 5, 2019 6:46 AM

To: The IESG <[email-masked]>

Cc: [email-masked]; Daniele Ceccarelli <[email-masked]>; [email-masked]; [email-masked]; [email-masked]

Subject: Alexey Melnikov's No Objection on draft-ietf-pce-wson-rwa-ext-11: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

COMMENT:

In Section 4.1:

        details.

YL>> The whole TLV.

In Section 4.3:

   field.

YL>> Yes.

   indicators).

                     Class List

YL>> Thanks for finding this out. Added TBD5 in Section 4.4 where “The encoding for the Optical Interface Class List (TBD5) is described …

   indicators).

YL>> Thanks for finding this out. Added TBD6 in Section 4.4 where “The encoding for the Client Signal information  (TBD6) is described …

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 07 Feb 2019 10:33:57 +0000

Hi,

>    o  Link Identifiers: Identifies each link ID for which restriction>    is applied. The length is dependent on the link format and the
>    Count>    field.

> *YL>> Yes.*

In this case the document is problematic, because length depends on the
particular link type, so if a receiver doesn't recognize a particular
link type, it wouldn't be able to parse the structure. (If this is by
design, you might want to be more explicit about this.)
You also need an IANA registry for link format types.

Best Regards,
Alexey

---

From: Leeyoung <[email-masked]>
Date: Wed, 13 Feb 2019 22:20:38 +0000

Hi Alexey,

My apology for the delay in responding to your comment. Please see inline for my response.

Thanks.
young

From: Alexey Melnikov [mailto:[email-masked]]
Sent: Thursday, February 7, 2019 4:34 AM
To: Leeyoung <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; Daniele Ceccarelli <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Alexey Melnikov's No Objection on draft-ietf-pce-wson-rwa-ext-11: (with COMMENT)

Hi,

In Section 4.3:

   field.

YL>> Yes.

In this case the document is problematic, because length depends on the particular link type, so if a receiver doesn't recognize a particular link type, it wouldn't be able to parse the structure. (If this is by design, you might want to be more explicit about this.)

YL>> What I meant extensible is that there are reserved field for the future use. We did not ask for IANA for this; instead, the PCE co-chair (please the attached email from Julien on this matter) suggested to re-use the existing registry defined in LMP. Please see the revised text in the last paragraph of Section 4.3.1:

  “The Type field is extensible. Please refer to the IANA registry
   allocated for Link Management Protocol (LMP) [RFC4204]:
   https://www.iana.org/assignments/lmp-parameters/lmp-
   parameters.xhtml#lmp-parameters-15.”

Do you think we still need IANA registry for link format types explicitly in this document?

Best Regards,
Alexey

Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-pce-wson-rwa-ext-11: (with DISCUSS and COMMENT)
From: "[email-masked]" <[email-masked]>
To: Benjamin Kaduk <[email-masked]>
Cc: Leeyoung <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Daniele Ceccarelli <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Alexey Melnikov <[email-masked]>
Date: Thu, 7 Feb 2019 11:24:36 +0000

Hi Young,

FWIW, the IANA already manages several similar registries with the same 3 entries (e.g., https://www.iana.org/assignments/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-15). Creating one will help addressing this concern raised by Alexey and Benjamin.

Thanks,

Julien

On 07/02/2019 02:27, Leeyoung wrote:

   What is the mechanism for extensibility of future Link Identifier sub-TLV types?  Should there be a registry?

   YL>>  I am not sure if we need reserve for future interface type. Typical PCEP/GMPLS RFCs do not go beyond this three types and the unnumbered type is flexible enough to accommodate other types than IPv4 and IPv6.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.