Re: [RTG-DIR] RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi,

This document has already completed Last Call (10/29), so it’s ready to go ahead as soon as the authors update for the directorate review comments. While GMPLS does support ITU-T data planes (OTN, WSON), this document is on PCE support for GMPLS. It is in support of already existing GMPLS specifications, nothing new w.r.t. data plane technologies. I don’t see the need to liaison. ITU-T has not indicated any interest in GMPLS or PCE evolution, we have not liaised in the past on our work on these protocols (except for ASON). If ITU-T is now evaluating use of GMPLS or PCE, I would suggest for folks cross-participating to encourage ITU-T to liaison us so we can support their efforts.

Thanks,
Deborah


From: David Sinicrope <[e-mail]>
Sent: Monday, November 19, 2018 9:05 AM
To: [e-mail]; [e-mail]; [e-mail]
Cc: 'Jonathan Hardwick' <[e-mail]>; [e-mail]; 'Yemin (Amy)' <[e-mail]>; [e-mail]; BRUNGARD, DEBORAH A <[e-mail]>
Subject: Re: [RTG-DIR] RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions


I agree with you both.  My comment was imprecise with the level of formality intended.   The intent was to make SG15 aware of this work given that many of the parameters and operations discussed and the target types of networks (i.e., OTN, WSON) would be of interest to that community.  I wasn't really thinking of a formal liaison exchange since a formal SG15 liaison response to IETF could not be approved until their June Plenary next year, well after this document would/should be published.  A short liaison to SG15 (specifically Working Party 3) in the manner Adrian suggests should do the trick.



Something like:

"The PCE working group would like to draw your attention to draft-ietf-pce-gmpls-pcep-extensions<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpce-2Dgmpls-2Dpcep-2Dextensions&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PedhR2jt7U3BUwkXLW1Yky_v_QLEfryKxWyMY7PlpcI&s=lJCPIRAjFdAlNayygZHB4O5SsWbnQebyjptZDqJDenM&e=>, which is currently is entering the approval stages of the IETF process.   This document, dealing with PCEP extensions for the GMPLS control plane, is targeted for operation with OTN and WSON networks and may be of interest to the SG15 community.  The IETF welcomes individual feedback and comments via the PCE email list <[e-mail]<mailto:[e-mail]>> from those interested.   While no formal liaison response is requested, any comments and feedback should be provided no later than <end of IETF last call date here>."



Thanks,

Dave



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

From: "Adrian uk>" <[e-mail]<mailto:[e-mail]>>

Date: Monday, November 19, 2018 at 8:04 AM

To: Julien Meuric <[e-mail]<mailto:[e-mail]>>, David Sinicrope <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

Cc: 'Jonathan Hardwick' <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "'Yemin (Amy)'" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, DEBORAH BRUNGARD <[e-mail]<mailto:[e-mail]>>

Subject: RE: [RTG-DIR] RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions



    I tend to agree with Julien.

    More eyes are always welcome, and sending a liaison statement or informal email pointing to the work and asking for feedback (from individuals not an official position of the ITU-T) on the PCE list before the end of last call (maybe IETF last call?) could not possibly be harmful, and would very probably be helpful.

    But a formal request for review seems a bit excessive.



    Cheers,

    Adrian



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

    From: rtg-dir <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>

    Sent: 19 November 2018 10:24

    To: David Sinicrope <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

    Cc: Jonathan Hardwick <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Yemin (Amy) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>

    Subject: Re: [RTG-DIR] RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions



    Hi all,



    Dave, thank you for this careful review. Though I'd by fine to liaise to ITU-T SG15 for information, I'm not that sure that our process requires liaising "for review": PCEP isn't a controversial technology which would need special treatment with respect to ITU-T. How strong do you feel on that?



    Cyril and authors, please make sure to address Dave's comments.



    Cheers,



    Julien





    On 18/11/2018 14:48, David Sinicrope wrote:

    >

    > Hello

    >

    > I have been selected to do a routing directorate “early” review of

    > this draft.

    > https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpce-2Dgmpls-2Dpcep-2Dextensions&d=DwQGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PedhR2jt7U3BUwkXLW1Yky_v_QLEfryKxWyMY7PlpcI&s=lJCPIRAjFdAlNayygZHB4O5SsWbnQebyjptZDqJDenM&e=>

    >

    > The routing directorate will, on request from the working group chair,

    > perform an “early” review of a draft before it is submitted for

    > publication to the IESG. The early review can be performed at any time

    > during the draft’s lifetime as a working group document. The purpose

    > of the early review depends on the stage that the document has reached.

    >

    > As this document is in working group last call, my focus for the

    > review was to determine whether the document is ready to be published.

    > Please consider my comments along with the other working group last

    > call comments.

    >

    > For more information about the Routing Directorate, please see

    > ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwQGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=PedhR2jt7U3BUwkXLW1Yky_v_QLEfryKxWyMY7PlpcI&s=NelJBaZHMUd4CneR8HzEb5M00RdglxbphLKZ3GxWaEc&e=>

    >

    > Document: draft-ietf-pce-gmpls-pcep-extensions-12.txt

    > Reviewer: David Sinicrope

    > Review Date: November 17, 2018

    > Intended Status: Standards Track

    >

    > *Summary:*

    >

    >   * This document is basically ready for publication, but has nits and

    >     clarifications that should be considered prior to being submitted

    >     to the IESG.

    >

    > *Comments:*

    >

    > Although a bit terse on motivation the document is of good quality and

    > detail providing the level of information needed for protocol

    > specification and implementation.

    >

    > The comments provided below are aimed at improving readability,

    > comprehension and consumption of the document by those that would use

    > it for architecture, solution design and implementation.

    >

    >

    >

    > Abstract.  Please provide some detail scope and purpose beyond one

    > line.  This is supposed to answer why / whether I should delve into

    > the document.

    >

    >

    >

    > General Comments (no particular section)

    >

    > 1. Given that this document is providing the detail for the

    > requirements in 7025, it might be advantageous to the reader to

    > structure the document according to the requirements listed in 7025.

    >

    >

    >

    > 2. The document gives a sparse highlight of what extensions are needed

    > and why Section 1 and then launches into the details in section2 and

    > on.  More elaboration on motivation and gaps and requirements would be

    > helpful to better understand why the extensions are needed.

    >

    >

    >

    > 3. This should be liaised to ITUT SG15 Q12 and Q14 for review.  Maybe

    > Q11/15 too.

    >

    >

    >

    > Sec 1.2 - RFC 7025 has 13 different requirements listed.

    >

    >

    >

    > 1. Why are they repeated here and not simply referenced? One must have

    > both documents to fully understand the requirements this document is

    > addressing, so there is no need to restate (and possibly misstate) the

    > agreed requirements here for readability

    >

    >

    >

    > 2. Why is this only a subset of the requirements in RFC 7025?  Is

    > there less covered here than in RFC7025?  If so this must be spelled

    > out in terms of coverage.  Perhaps a table to explain the functions

    > noted in 7025 vs what this document covers.

    >

    >

    >

    >

    >

    > Introduction - this document assumes a significant familiarity with

    > rfc7025 and the other documents listed.  It should state this outright.

    >

    >

    >

    >

    >

    > Sec 1.3 - please correlate these to the requirements they are

    > addressing.  Also please provide more explanation.  Some of these are

    > seemingly contradictory the way they are listed currently. E.g.

    > END-POINTS and ERO make it sound confused as to whether the 7025

    > requirement on unnumbered interfaces is addressed  or not.

    >

    > Some examples would go a long way to providing clarity

    >

    > Note: I noted this is done later in the specific extensions, but could

    > also be done here.

    >

    >

    >

    > Sec 1.3 - PCEP objects, needs plural

    >

    >

    >

    > Sec 1.3 - they can’t be shortcomings if they were not designed for the

    > use noted.  Perhaps “gaps in functional coverage” or “areas for

    > enhancement” is a better description.

    >

    >

    >

    > Sec 1.3 - why is the infusion/exclusion of labels a shortcoming?

    > Please elaborate.

    >

    >

    >

    > Sec 1.3 – Protection should be listed with the others “shortcomings”

    > right now looks like a summary which it isn’t.  Indent this text.

    >

    >

    >

    > Sec 1.3 covered pcep extensions - covered by what? This document?  If

    > so, please say so. Also say/elaborate on why they are needed.  Note: I

    > can see this is done much more in the individual sections describing

    > the extension.  It would suffice then to add a note here that more

    > detail on motivation is provided with each individual extension.

    >

    >

    >

    > Sec 2.2 - excellent cross reference to RFC 7025. I see this is done

    > elsewhere.  This makes addressing solution architecture most helpful.

    >

    > *Nits:*

    >

    > Miscellaneous warnings:

    >

    >

    > ----------------------------------------------------------------------

    > ------

    >

    >

    >

    >   == Line 1206 has weird spacing: '...ted bit  routi...'

    >

    >

    >

    >   -- The document date (September 27, 2018) is 52 days in the past. Is

    > this

    >

    >      intentional?

    >

    >

    >

    >

    >

    > *From: *DEBORAH BRUNGARD <[e-mail]<mailto:[e-mail]>>

    > *Date: *Monday, October 15, 2018 at 12:07 PM

    >

    >

    >

    > Hi Authors (and Shepherd),

    >

    >

    >

    > I thought your document was well written and considering how long we

    > have been waiting for this document😊, I have started IETF Last Call.

    > I’ve started the IETF Last Call due to the window closing in on the

    > next IETF meeting when the other Areas prefer not to have Last Calls

    > overlapping. Dave Sinicrope will be the rtg-dir reviewer and will do

    > his review in parallel with Last Call.

    >

    >

    >

    > Please be sure to have one of you available as the main pen holder to

    > be responsive to Dave, other Area Directorate reviewers comments, and

    > IESG comments.

    >

    >

    >

    > Thanks!

    >

    > Deborah

    >

    >

    >

    >

    >





    _________________________________________________________________________________________________________________________



    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.