Re: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec

[Zhuangshunwan]

Hi all,

This draft provides a useful method to assign flows to the Tunnels controlled 
by the PCE.
I think it is stable and mature. And I support the publication.

Thanks,
Shunwan

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of julien.meu...@orange.com
Sent: Monday, October 14, 2019 8:55 PM
To: pce@ietf.org
Subject: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec

Hi all,

In our WGLC queue, draft-ietf-pce-pcep-flowspec has been stable for a while. 
This message starts a 2-week WG last call on this I-D. Please review the 
document and share your feedback using the PCE mailing list by Monday October, 
28.

You will note that the I-D includes an implementation section. If you have an 
implementation, you may also contact the chairs privately.

Thanks,

Dhruv & Julien


_

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.

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

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

Re: [Pce] IPR Poll on draft-ietf-pce-pcep-flowspec

[Zhuangshunwan]

Hi Hari,

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Best Regards,
Shunwan as a contributor




From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Hariharan Ananthakrishnan
Sent: Tuesday, October 15, 2019 1:00 AM
To: Dhruv Dhody ; Farrel Adrian ; 
Lizhenbin 
Cc: pce@ietf.org
Subject: [Pce] IPR Poll on draft-ietf-pce-pcep-flowspec


Hi Authors,



In preparation for Working Group last call on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.



Please respond (copying the mailing list) to say one of:



I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec

[Adrian Farrel]

Hi Julien,

Probably no surprise: as an author, I support this document going forward.

I just did a quick re-read of the draft and don't see any issues beyond the
fact that Section 11 refers to the -04 version.

Thanks,
Adrian

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: 14 October 2019 13:55
To: pce@ietf.org
Subject: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec

Hi all,

In our WGLC queue, draft-ietf-pce-pcep-flowspec has been stable for a
while. This message starts a 2-week WG last call on this I-D. Please
review the document and share your feedback using the PCE mailing list
by Monday October, 28.

You will note that the I-D includes an implementation section. If you
have an implementation, you may also contact the chairs privately.

Thanks,

Dhruv & Julien



_

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.

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

___
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

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

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-gmpls-pcep-extensions-14: (with DISCUSS and COMMENT)

[Cyril Margaria]

Thanks for the thorough review, a new version addressing the comments has
been posted,

please see inline

A new version

On Thu, 11 Apr 2019 at 12:46, Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-pce-gmpls-pcep-extensions-14: Discuss
>
> 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-gmpls-pcep-extensions/
>
>
>
> --
> DISCUSS:
> --
>
> This document makes some well-needed extensions to existing PCEP
> concepts such as bandwidth, but I'm not convinced that the way they
> interact with existing PCEP functionality is sufficiently well specified
> to admit interoperable implementation.  Specifically, we introduce the
> generalized bandwidth structures and reuse that encoding for the
> generalized load balancing structures, which includes a notion of
> "minimum bandwidth specification".  But now that the bandwidth
> specification is a compound data structure instead of a scalar type,
> it's not guaranteed that we have a strict linear ordering with
> well-defined minimum.  If we consider the specific case of Intserv, do I
> insist upon all three of the minimum bucket rate, minimum bucket size,
> and minimum peak data rate?  Or perhaps I only care about the peak data
> rate and not the bucket size/rate.  We need more text in order to
> specify what "minimum" actually means/measures.
>
> Similarly, I'm not sure all the referenced generalized bandwidth
> types/traffic parameters in Section 2.3 clearly indicate which
> structures/fields we are to incorporate by reference (see COMMENT).
>
>
[MC] Thanks Julien for the text that was agreed on; it has been
incorporated in the new version.

OLD
   The semantic of the LOAD-BALANCING object is not changed.  If a PCC
   requests the computation of a set of TE-LSPs so that the total of
   their generalized bandwidth is X, the maximum number of TE-LSPs is N,
   and each TE-LSP must at least have a bandwidth of B, it inserts a
   BANDWIDTH object specifying X as the required bandwidth and a LOAD-
   BALANCING object with the Max-LSP and Min Bandwidth Spec fields set
   to N and B, respectively.

NEW
   The semantic of the LOAD-BALANCING object is not changed.  If a PCC
   requests the computation of a set of TE-LSPs with at most N TE-LSPs
   so that it can carry generalized bandwidth X , each TE-LSP must at
   least transport bandwidth B, it inserts a BANDWIDTH object specifying
   X as the required bandwidth and a LOAD-BALANCING object with the Max-
   LSP and Min Bandwidth Spec fields set to N and B, respectively.  When
   the BANDWIDTH and Min Bandwidth Spec can be summarized as scalars,
   the sum of all TE-LSPs bandwith in the set is greater than X.  The
   mapping of X over N path with (at least) bandwidth B is technology
   and possibly node specific.  Each standard definition of the
   transport technology is defining those mappings and are not repeated
   in this document.  A simplified example for SDH is described in
   Appendix A


   In all other cases, including for technologies based on statistical
   multiplexing (e.g., InterServ, Ethernet), the exact bandwidth
   management (e.g., Ethernet's Excessive Rate) is left to the PCE's
   policies, according to the operator's configuration.  If required,
   further documents may introduce a new mechanism to finely express
   complex load balancing policies within PCEP.



> Section 2.1.2 says:
>
>GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use
>of the objects and TLVs defined in this document.
>
> Why is this not "the PCC MUST NOT make use of the objects and TLVs
> defined in this document"?  Ignoring the peer's (non-)advertisement and
> plowing ahead seems like a recipe for non-interoperability.
>
>

[MC] The PCC is able to mandate or not the processing of objects on
per-request basic. To make it simpler the capability negotiation has
been made mandatory (both peer must advertize the capability).


Section 2.5.1 notes that:
>
>   ::=
> []
>[ []]...
>
>
>For endpoint type Point-to-Multipoint, several endpoint objects MAY
>be present in the message and each represents a leave, exact meaning
>depend on the endpoint type defined of the object.
>
> If all s represent leaves, then how is the head node
> specified?
>
>
[MC] In case of P2P the first endpoint is the ingress and the second is
egress.
In case of P2MP, the first endpoint is root and 

[Pce] I-D Action: draft-ietf-pce-gmpls-pcep-extensions-15.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP extensions for GMPLS
Authors : Cyril Margaria
  Oscar Gonzalez de Dios
  Fatai Zhang
Filename: draft-ietf-pce-gmpls-pcep-extensions-15.txt
Pages   : 44
Date: 2019-10-17

Abstract:
   A Path Computation Element (PCE) provides path computation functions
   for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   networks.  Additional requirements for GMPLS are identified in
   RFC7025.

   This memo provides extensions to the Path Computation Element
   communication Protocol (PCEP) for the support of the GMPLS control
   plane to address those requirements.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-gmpls-pcep-extensions-15
https://datatracker.ietf.org/doc/html/draft-ietf-pce-gmpls-pcep-extensions-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-pcep-extensions-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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