[Pce] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14

[Elwyn Davies via Datatracker]

Reviewer: Elwyn Davies
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-pce-gmpls-pcep-extensions-14
Reviewer: Elwyn Davies
Review Date: 2019-04-10
IETF LC End Date: 2018-10-29
IESG Telechat date: 2019-04-11

Summary:
Almost ready, but with a large collection of nits in language and non-expansion
of abbreviations. I am also concerned about the specification of behaviour in
case PCC/PCEs with and without the extensions attempt to interact.  The
requirements and behaviour are rather woolly, and are not fully covered by
capability negotiations as the negotation capability itself is not in the
original PCEP specification.

Major issues:
None

Minor issues:
Interacting with PCCs that do not support these GMPLS extensions: The draft is
not very clear on interactions between PCCs that do support the extensions and
ones that do not.  It is unclear whether a PCC that proposes to use the
extensions must support the RFC 5088 or 5089 capability negotiation extensions
and use them to determine if a PCEP exchange can use the extensions.  The text
in para 1 of s2.1.2 appears to require that a node that does not support RFC
5088 or 5089 still has to understand that it has received the GMPLS-CAPABILITY
type indicator and indicate a mismatch.  It seems to me that some additional
explanation is needed to describe how mismatched PCC/PCEs understand the
problem and deal with cases where a message with the new extensions is received
(and presumably rejected) by a node that does not implement the extensions.

s9.2, RFC7025: Given the references to the requirements document for this work,
I would consider RFC 7025 to be normative.

Nits/editorial comments:
General: s/e.g. /e.g., /g

Abstract: s/The Path Computation Element (PCE)/A Path Computation Element (PCE)/

s1: Expand abbreviations OTN (Optical Transport Networks) and WSON (Wavelength
Switched Optical Networks).

s1, para 2: s/considered/addressed/, s/those application/these applications/

s1.2, para 1: s/PCEP extension/PCEP extensions/, s/broken down in/broken down
into/

s1.2: Expand following acronyms/abbreviations on first occurrence: LSP, TE-LSP,
L2SC, TDM, SONET, SDH, LSC [Query: Is LSC different from L2SC?], PCC, ERO

s1.2, bullet 2: A reference for the G.709 standard is needed.

s1.2 and s1.3.1, items (4) and (5): There doesn't seem to be a definition of
Concatenation Number in any of the documents mentioned here or anywhere on the
web.  I suspect it is supposed to be the number of streams that are
concatenated but this needs to be properly defined or a reference provided.

s1.2, bullet 5:  s/Label restriction/label restriction/.  I take it this refers
to the use of Label Set objects as described in RFC 3473.  If so please add a
reference.  If not lease provide the appropriate reference.

s1.3.1: Expand following acronyms/abbreviations on first occurrence: TE-LSP,
ODU, IRO, XRO, RRO, LSPA

s1.3.1, item (4): s/Its scoped/It is scoped/ [English language note: 'Its' is
the possessive pronoun derived from the third person singular impersonal
pronoun 'it', whereas "It's" is a contraction of 'it is' that is not normally
used in formal documents.]

s1.3.1, item (4):

> related to the BANDWIDTH object in MPLS networks
I assume this relates to the BANDWIDTH object in RFC 5440 - please add a
reference.

s1.3.2, item (1):  The previous two comments on s.1.3.1, item (4) apply also to
this item.

s1.4:

OLD:

 1.4   GMPLS Support and Limitation of Base PCEP Objects

   The support for requirements [RFC7025] is summarized in Table 1 and
   Table 2

NEW:

1.4   Existng Support for GMPLS in Base PCEP Objects and its Limitations

   The support provided by specifications in [RFC8282] and [RFC5440]  for the
   requirements listed in [RFC7025] is summarized in Table 1 and Table 2.  In
   some cases the support may not be complete, as noted, and additional support
   need to be provided in this specification.

ENDS

s1.4, RFC 5440 bullets, ERO:  A reference for the RSVP specification covering
ERO is needed.

s1.4, XRO object. 1st bullet: Expand SRLG.

s1.4, SWITCH-LAYER bullet: s/address/addresses/

s1.4, list of coverage gaps: Expand NVC.

s1.4, added functionality needed: s/to cover the gap/to cover the gaps/

s2: Expand PCReq and PCRep message names to reflect names in RFC 5440.

s2.1.2:

> Moreover, in case that the PCC does not receive the
>GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use
>of the objects and TLVs defined in this document.
I would have thought this ought to have been a MUST (when communicating with
the PCC that didn't support the extensions.

s2.1.2: s/OPEN message/Open message/

Re: [Pce] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14

[Cyril Margaria]

Thanks for the review,

a new version has been posted addressing your comments.
Please also see inline

On Wed, 10 Apr 2019 at 13:47, Elwyn Davies via Datatracker 
wrote:

> Reviewer: Elwyn Davies
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-pce-gmpls-pcep-extensions-14
> Reviewer: Elwyn Davies
> Review Date: 2019-04-10
> IETF LC End Date: 2018-10-29
> IESG Telechat date: 2019-04-11
>
> Summary:
> Almost ready, but with a large collection of nits in language and
> non-expansion
> of abbreviations. I am also concerned about the specification of behaviour
> in
> case PCC/PCEs with and without the extensions attempt to interact.  The
> requirements and behaviour are rather woolly, and are not fully covered by
> capability negotiations as the negotation capability itself is not in the
> original PCEP specification.
>
> Major issues:
> None
>
> Minor issues:
> Interacting with PCCs that do not support these GMPLS extensions: The
> draft is
> not very clear on interactions between PCCs that do support the extensions
> and
> ones that do not.  It is unclear whether a PCC that proposes to use the
> extensions must support the RFC 5088 or 5089 capability negotiation
> extensions
> and use them to determine if a PCEP exchange can use the extensions.  The
> text
> in para 1 of s2.1.2 appears to require that a node that does not support
> RFC
> 5088 or 5089 still has to understand that it has received the
> GMPLS-CAPABILITY
> type indicator and indicate a mismatch.  It seems to me that some
> additional
> explanation is needed to describe how mismatched PCC/PCEs understand the
> problem and deal with cases where a message with the new extensions is
> received
> (and presumably rejected) by a node that does not implement the extensions.
>
> [MC] The IGP-based discovery (RFC 5088 or 5089) are optional, and are
not capability negotiations. The Capability negotiation is done only
in PCEP, and the GMPLS-CAPABILITY TLV must be present from both peers
in order to make use of the extensions


> s9.2, RFC7025: Given the references to the requirements document for this
> work,
> I would consider RFC 7025 to be normative.
>
> [MC] 7025 is marked as Informational, so I am not sure it should
listed as normative.


> Nits/editorial comments:
>

[MC] All the nits have addressed


> General: s/e.g. /e.g., /g
>
Abstract: s/The Path Computation Element (PCE)/A Path Computation Element
> (PCE)/
>
> s1: Expand abbreviations OTN (Optical Transport Networks) and WSON
> (Wavelength
> Switched Optical Networks).
>
> s1, para 2: s/considered/addressed/, s/those application/these
> applications/
>
> s1.2, para 1: s/PCEP extension/PCEP extensions/, s/broken down in/broken
> down
> into/
>
> s1.2: Expand following acronyms/abbreviations on first occurrence: LSP,
> TE-LSP,
> L2SC, TDM, SONET, SDH, LSC [Query: Is LSC different from L2SC?], PCC, ERO
>
> s1.2, bullet 2: A reference for the G.709 standard is needed.
>
> s1.2 and s1.3.1, items (4) and (5): There doesn't seem to be a definition
> of
> Concatenation Number in any of the documents mentioned here or anywhere on
> the
> web.  I suspect it is supposed to be the number of streams that are
> concatenated but this needs to be properly defined or a reference provided.
>
> s1.2, bullet 5:  s/Label restriction/label restriction/.  I take it this
> refers
> to the use of Label Set objects as described in RFC 3473.  If so please
> add a
> reference.  If not lease provide the appropriate reference.
>
> s1.3.1: Expand following acronyms/abbreviations on first occurrence:
> TE-LSP,
> ODU, IRO, XRO, RRO, LSPA
>
> s1.3.1, item (4): s/Its scoped/It is scoped/ [English language note: 'Its'
> is
> the possessive pronoun derived from the third person singular impersonal
> pronoun 'it', whereas "It's" is a contraction of 'it is' that is not
> normally
> used in formal documents.]
>
> s1.3.1, item (4):
>
> > related to the BANDWIDTH object in MPLS networks
> I assume this relates to the BANDWIDTH object in RFC 5440 - please add a
> reference.
>
> s1.3.2, item (1):  The previous two comments on s.1.3.1, item (4) apply
> also to
> this item.
>
> s1.4:
>
> OLD:
>
>  1.4   GMPLS Support and Limitation of Base PCEP Objects
>
>The support for requirements [RFC7025] is summarized in Table 1 and
>Table 2
>
> NEW:
>
> 1.4   Existng Support for GMPLS in Base PCEP Objects and its Limitations
>
>The support provided by specifications in [RFC8282] and [RFC5440]  for
> the
>requirements listed in [RFC7025] is summarized in Table 1 and Table 2.
> In
>some cases the support may not be complete, as noted, and additional
> su

Re: [Pce] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14

[Benjamin Kaduk]

On Thu, Oct 17, 2019 at 02:48:00PM +0100, Cyril Margaria wrote:
> Thanks for the review,
> 
> a new version has been posted addressing your comments.
> Please also see inline
> 
> On Wed, 10 Apr 2019 at 13:47, Elwyn Davies via Datatracker 
> wrote:
> 
> 
> 
> > s9.2, RFC7025: Given the references to the requirements document for this
> > work,
> > I would consider RFC 7025 to be normative.
> >
> > [MC] 7025 is marked as Informational, so I am not sure it should
> listed as normative.

The status (Informational/PS/etc.) of a reference is not relevant to
whether the reference is properly normative or informative.  Please see
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
for further background -- if a normative reference on an Informational
document is needed, the responsible AD will take care of making that work,
procedurally.

-Ben

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14

[BRUNGARD, DEBORAH A]

Hi Elwyn, Benjamin,

Much thanks for the careful review!

Ben is correct that an Informational document can be normatively referenced. 
There are differences in how the different working groups do references. In 
PCE, requirements documents are not usually normatively referenced (e.g. 5540, 
8231, 8623 just to name a quick couple). Especially as with this document, a 
summary is provided of the terms and requirements. And the document does 
normatively reference more than 20 GMPLS documents which are the necessary ones 
for understanding implementation and the basis of the work.

Unless the authors, chairs, working group have changed their interpretation, I 
agree this reference is informative.

Thanks!
Deborah
 

-Original Message-
From: Benjamin Kaduk  
Sent: Monday, October 21, 2019 3:35 PM
To: Cyril Margaria 
Cc: Elwyn Davies ; gen-...@ietf.org; 
draft-ietf-pce-gmpls-pcep-extensions@ietf.org; pce@ietf.org; i...@ietf.org
Subject: Re: [Pce] Genart telechat review of 
draft-ietf-pce-gmpls-pcep-extensions-14

On Thu, Oct 17, 2019 at 02:48:00PM +0100, Cyril Margaria wrote:
> Thanks for the review,
> 
> a new version has been posted addressing your comments.
> Please also see inline
> 
> On Wed, 10 Apr 2019 at 13:47, Elwyn Davies via Datatracker 
> 
> wrote:
> 
> 
> 
> > s9.2, RFC7025: Given the references to the requirements document for 
> > this work, I would consider RFC 7025 to be normative.
> >
> > [MC] 7025 is marked as Informational, so I am not sure it should
> listed as normative.

The status (Informational/PS/etc.) of a reference is not relevant to whether 
the reference is properly normative or informative.  Please see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_about_groups_iesg_statements_normative-2Dinformative-2Dreferences_&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=cjIGq8MdFpzTHZnHDJ7oSYY0AALP5ePN_V5HGddlfp0&s=E6DoKmUBMTYqyAGkcga-bvCVaIkfO2l4sTdxZHc11d4&e=
for further background -- if a normative reference on an Informational document 
is needed, the responsible AD will take care of making that work, procedurally.

-Ben

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce