From nobody Fri Jul 1 03:20:53 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D898412D53A for ; Fri, 1 Jul 2016 03:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m5RZoRgYQ3x for ; Fri, 1 Jul 2016 03:20:49 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E92B12D536 for ; Fri, 1 Jul 2016 03:20:48 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id a66so22679820wme.0 for ; Fri, 01 Jul 2016 03:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=7T89gmfvOI5EOyq/I04B7p/9mUQLIGxodlzKB4HbRhk=; b=ypdeZqExrExbODXeOV5MZ38scJMJHXEdTJpqtgNgmJ6rbpD/O1HThUMUEZ5aj8mb0I /At+8aq387STvH/drgOf/BKkfDVUdNIUUHhddAVfoFQakZwz8SU1vYHg/Jz77Jqc7RXb aWkx/bOhT1LF7vWXcYzefLp5OPR4X9PkL/gDB6uCs9B63KqgN4A7T9nxMjOuTK6nsmL9 bfEPH/FHtVX4rZnUCT/yWuNDuadqFh0U//EWISfkmG7wpaJ+bXuuLV1aDPVUOJGB/RYc si+fQ4LvlPKX7ucubIKGXtvxc+WiPc2cPFRE/AfuMPIcYyNrcbajInCpsBeUPtP0JZOm qdsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:thread-index:content-language; bh=7T89gmfvOI5EOyq/I04B7p/9mUQLIGxodlzKB4HbRhk=; b=hyQj95q0tvB+ypcspsvqKUi29X6+RGszlfG+MCco9LJX3ygO8NhyXzGd3ep185l2FO KSFHU2BIK+NYuHDRx1yG0388RwPxVPZxl3Hzuvv8g9FIWKiZ2KlDE6ZyuAj2v9MWcmiG ZZsCxzqzZaX+ILTOkh7AwoPdk8iWn0Yl0kMitIIyDv4DvIjni6CeSm3J+3Bp8cXMtH0n r6o/t4kekOj96Nr9qtbqzxdiHp1GNyx2fnXURHNVZYKfJbgCVZ+raLDoWc5WO7z8HTXG oD/w7pGMKX/IgBjqBdjTCLgePWRWxI3StM9hZE7n7SUCSKHIs7/4CUcHn/iNWPJwiE4E suvw== X-Gm-Message-State: ALyK8tLQBjvtgXBWG4Fw0/lE2uUC4ClqgstS98p9BBkb1pM1SIZ0LQKCbTV5ggrKkCYWBw== X-Received: by 10.194.104.227 with SMTP id gh3mr2860470wjb.3.1467368447379; Fri, 01 Jul 2016 03:20:47 -0700 (PDT) Received: from FIREFLY (vpn-234.nat.lancs.ac.uk. [148.88.244.234]) by smtp.gmail.com with ESMTPSA id p191sm2095865wme.7.2016.07.01.03.20.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jul 2016 03:20:46 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: Date: Fri, 1 Jul 2016 11:20:46 +0100 Message-ID: <003c01d1d382$3be09c00$b3a1d400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01D1D38A.9DA5C750" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdHTf1VdkURiySrfRvWoClnNKolOqw== Content-Language: en-gb Archived-At: Subject: [Pce] New (01) version of PCEP Experimental Codepoint Allocation X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 10:20:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01D1D38A.9DA5C750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, We just posted a new version of the I-D based on comments received from the list. Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP) https://tools.ietf.org/html/draft-dhody-pce-pcep-exp-codepoints-01 Updates include: - Suggested experimental codepoint range for PCEP: Messages, Objects, and TLVs - Captured the list discussion on NO-PATH Objects, Metric Types, Notifications, Errors and Close Messages - Added a table summarising registry requests. Obviously further discussion of the document is needed, and we hope to present the proposal in Berlin. A few key questions for consideration, include: - The WG needs to decide on the scope of the experimental code points - Do we need a new experimental Error-value/Notification-Value if an existing Error-Type/Notification-Type is not allowed, or should we add a new Error-type/Notification-Type from experimental range/value? - Or, should we set aside an experimental range for Error-value/Notification-Value for each Error-Type/Notification-Type as well. - How best to meet Johns requirement of prime-based number allocations, as it seems Fibonacci numbers are not acceptable. See some of you in Berlin! BR, Dan and Dhruv. ------=_NextPart_000_003D_01D1D38A.9DA5C750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

We just = posted a new version of the I-D based on comments received from the = list.

 

Experimental Codepoint Allocation for Path Computation = Element communication Protocol (PCEP)

https://tools.ietf.org/html/draft-dhody-pce-pcep-exp-codepoints-01=

 

Updates include:

 

- Suggested = experimental codepoint range for PCEP:  Messages, Objects, and = TLVs

- Captured the list discussion = on NO-PATH Objects, Metric Types, Notifications, Errors and Close = Messages

- Added a table summarising = registry requests.

 

Obviously = further discussion of the document is needed, and we hope to present the = proposal in Berlin. A few key questions for consideration, = include:

 

- The WG needs to decide on the scope of the = experimental code points

- Do we need = a new experimental Error-value/Notification-Value if an existing = Error-Type/Notification-Type is not allowed, or should we add a new = Error-type/Notification-Type from experimental = range/value?

- Or, should we set = aside an experimental range for Error-value/Notification-Value for each = Error-Type/Notification-Type as well.

- How best to meet Johns requirement of prime-based = number allocations, as it seems Fibonacci numbers are not acceptable. =

 

See some of you in Berlin!

 

BR, Dan and = Dhruv.

 

         &= nbsp;           &n= bsp;       =

------=_NextPart_000_003D_01D1D38A.9DA5C750-- From nobody Tue Jul 5 16:22:27 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9426812D115 for ; Tue, 5 Jul 2016 16:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyvPKJJr0VVK for ; Tue, 5 Jul 2016 16:22:24 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9D512D0D9 for ; Tue, 5 Jul 2016 16:22:23 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id g4so53942310ith.1 for ; Tue, 05 Jul 2016 16:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sW2n+G5i1UHCMRPo/24j9yQwD6lkQnIklm46+gvF0Mo=; b=HMFLwIth+MdBwIeWe/zHRp4fjnhOVS+yBt3B/NXoA5y2L9iBl74AH/0sQocfaD3ng+ ernDpcbXYjk3ZhoLtAMr2CGkJsrgIMNJ3SJ9fsJItkHlZ/WqucWpOfDbNXScLaKitr3q lEdqRWSsuVRDRieSn7p1FnlOTZ+QPULLRr39XxR6k1olEnJJMOb8qGo/BvoCDAJvXSdI 2MC7/8C5QGJtkOtgUMJtjHalPYa2wITJMtx2VzKMgVNBm2zJWJAH7LQ/WEAmBizNZZ6b /7JuCzm8exkhum/tJwAY4DPk1ldQ+nYT29iRAV3+06nqP9RD+zuQRlMDqX9Ri+shvFD/ zy+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sW2n+G5i1UHCMRPo/24j9yQwD6lkQnIklm46+gvF0Mo=; b=W31hZ3SsBgvLFby04YL1sI0nrkjzhRClyK7zcEsN+6dnbLNiaB/EnK4KhxHN/hDXyX j0JMEFF9+Zlvyt/LVR7bzgwZegCN3ZT2wjS3EQdRfEPADl0ofWM9yTI8ak5EylLJMfMW qiCx3zaD42iyT0OgS2Vac1R2UD3lpmiN9wjDLIS3M/wqiapgqaQTxJMFz3XiZ/l3FfeH Os94xb/Z3g3Ugkz3uf29uzRWnYQOp9eNdHCuu8OXZ3wnNTSVFeUSDfwHmuOTTcmxNEic X5oKq/CZssUZsaJ6LiKlJ280IiOxzxpfXsvBP64GOngUBKBQdLsViF24SaL+NoP9Ozcv EhmQ== X-Gm-Message-State: ALyK8tLvrKynrEpUwpuPFtM1mJ5vHRWffx2HqHo1qzG3tFlnXvS0hPWSzz0k2voiH6ASrqVoPsPyxFDLYbXy3A== X-Received: by 10.36.184.3 with SMTP id m3mr2148566ite.90.1467760943217; Tue, 05 Jul 2016 16:22:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.129.103 with HTTP; Tue, 5 Jul 2016 16:22:22 -0700 (PDT) In-Reply-To: <834ECFC1-5C8F-4E29-BD22-D8F006BC1564@netcracker.com> References: <834ECFC1-5C8F-4E29-BD22-D8F006BC1564@netcracker.com> From: Girish Birajdar Date: Tue, 5 Jul 2016 16:22:22 -0700 Message-ID: To: Andrew Veitch , draft-ietf-pce-pce-initiated-lsp@tools.ietf.org Content-Type: multipart/alternative; boundary=94eb2c111cbaa2c30f0536ebb938 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Status of draft-ietf-pce-pce-initiated-lsp X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 23:22:26 -0000 --94eb2c111cbaa2c30f0536ebb938 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, about #5.4 LSP deletion " A PLSP-ID of zero removes all LSPs that were initiated by the PCE... Following the removal of the LSP, the PCC MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce]. The SRP object in the PCRpt MUST include the SRP-ID-number from the PCInitiate message that triggered the removal. The R flag in the SRP object SHOULD be set. " The draft needs to clarify PCRpt message for such cases: 1. Does PCC send single PCRpt (with SRP-ID)? 2. PCC sends PCRpt for each deleted LSP. In such cases PCE will have to accept multiple PCRpt with same SRP-ID. Thanks -Girish On Wed, Jun 1, 2016 at 1:36 PM, Andrew Veitch wrote: > > Hi, > > Is there an update regarding this draft and/or any additional supporting > work needed? Thanks. > > Andy > > > Re: [Pce] Status of draft-ietf-pce-pce-initiated-lsp > "Adrian Farrel" Tue, 03 May 2016 19:16 UTC > > Hi Ina, > Great that you have this under control. > > Looks like "review and review" are the actions on me. > Will do. > > Cheers, > Adrian > > From: Ina Minei [mailto:inaminei@google.com ] > Sent: 02 May 2016 17:17 > To: 'Adrian Farrel' (adrian@olddog.co.uk) > Cc: pce; draft-ietf-pce-pce-initiated-lsp@ietf.org > Subject: Re: Status of draft-ietf-pce-pce-initiated-lsp > > Adrian, > > Thank you for bringing this up. I will repost the initiation draft, I am = aware that it expired. Before doing so, will reply to what I think is the u= nfinished thread ( https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pby= g1eCHw3YMVE) , please let me know if there was a different thread that you = are referring to. Thank you for bringing this up, this had completely falle= n through the cracks on my end. > > Thank you for your offer to help with the stateful PCE I-D. Your help wou= ld be appreciated in letting us know if there are pending changes needed, a= s I > am assuming that the version posted a month ago addressed all issues, wan= t to make sure this is not a similar situation as the initiation draft. > > Thank you, > > Ina > > > On Tue, Apr 26, 2016 at 1:45 AM, Adrian Farrel wrot= e: > Hi All, > > In Buenos Aires Jon presented the WG status (thanks) and showed that > draft-ietf-pce-pce-initiated-lsp is "Pending shepherd review". > > Just looking now (because quite a lot of new work seems to depend on the > PCInitiate message) I see that: > > - The I-D expired a couple of days ago (April 21, 2016) > > - The last discussion on the list was an email from Julien suggesting tha= t > some work was needed to address open questions on the list. > > I'd like to see this I-D move forward now (as well as the stateful PCE I-= D!). > Can I offer my assistance to the authors in any way? I am willing to shov= el > shit, or just make editorial changes. > > Let's dig the WG out of the treacle and start to be relevant again :-) > > Thanks, > Adrian > > > > > ------------------------------ > The information transmitted herein is intended only for the person or > entity to which it is addressed and may contain confidential, proprietary > and/or privileged material. Any review, retransmission, dissemination or > other use of, or taking of any action in reliance upon, this information = by > persons or entities other than the intended recipient is prohibited. If y= ou > received this in error, please contact the sender and delete the material > from any computer. > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --94eb2c111cbaa2c30f0536ebb938 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

about #5.4 LSP deletion
&qu= ot; A =C2=A0PLSP-ID of zero removes all LSPs that were initiated by the PCE= ...
=C2=A0=C2=A0 Following the removal of the LSP, the PCC
=C2=A0 =C2= =A0MUST send a PCRpt as described in [I-D.ietf-pce-stateful-pce].=C2=A0 The=
=C2=A0 =C2=A0SRP object in the PCRpt MUST include the SRP-ID-number fro= m the
=C2=A0 =C2=A0PCInitiate message that triggered the removal.=C2=A0 = The R flag in the SRP
=C2=A0 =C2=A0object SHOULD be set.
"
The draft needs to clarify PCRpt message for such cases:
1. Does PCC s= end single PCRpt (with SRP-ID)?
2. PCC sends PCRpt for each deleted LSP.= In such cases PCE will have to accept multiple PCRpt with same SRP-ID.
=
Thanks
-Girish


On Wed, Jun 1, 2016 at 1:36= PM, Andrew Veitch <andrew.veitch@netcracker.com>= wrote:

Hi,

Is there an update regarding this draft and/or any additional supporti= ng work needed? =C2=A0 Thanks.

Andy


Re: [Pce] Status of draft-ietf-pce-pce-initiated-lsp

= "Adrian Farrel" <= adrian@olddog.co.uk>=C2=A0Tue, 03 May 2016 19:16 UTC
Hi Ina,
Great that you have this under control.
=20
Looks like "review and review" are the actions on me.
Will do.
=20
Cheers,
Adrian
=20
From: Ina Minei [m=
ailto:inaminei@google.com]=20
Sent: 02 May 2016 17:17
To: 'Adrian Farrel' (adrian@olddog.co.uk)
Cc: pce; draft-ietf-pce-pce-initiated-lsp@ietf.org
Subject: Re: Status of draft-ietf-pce-pce-initiated-lsp
=20
Adrian,=20
=20
Thank you for bringing this up. I will repost the initiation draft, I am aw=
are that it expired. Before doing so, will reply to what I think is the unf=
inished thread (  <https://mailarchive.ietf.org=
/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE> =
https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE) =
, please let me know if there was a different thread that you are referring=
 to. Thank you for bringing this up, this had completely fallen through the=
 cracks on my end.=20
=20
Thank you for your offer to help with the stateful PCE I-D. Your help would=
 be appreciated in letting us know if there are pending changes needed, as =
I=20
am assuming that the version posted a month ago addressed all issues, want =
to make sure this is not a similar situation as the initiation draft.=20
=20
Thank you,=20
=20
Ina=20
=20
=20
On Tue, Apr 26, 2016 at 1:45 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi All,

In Buenos Aires Jon presented the WG status (thanks) and showed that
draft-ietf-pce-pce-initiated-lsp is "Pending shepherd review".

Just looking now (because quite a lot of new work seems to depend on the
PCInitiate message) I see that:

- The I-D expired a couple of days ago (April 21, 2016)

- The last discussion on the list was an email from Julien suggesting that
   some work was needed to address open questions on the list.

I'd like to see this I-D move forward now (as well as the stateful PCE =
I-D!).
Can I offer my assistance to the authors in any way? I am willing to shovel
shit, or just make editorial changes.

Let's dig the WG out of the treacle and start to be relevant again :-)

Thanks,
Adrian

= =C2=A0

=

The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons or entities other than the inte= nded recipient is prohibited. If you received this in error, please contact= the sender and delete the material from any computer. =C2=A0


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


--94eb2c111cbaa2c30f0536ebb938-- From nobody Wed Jul 6 06:38:33 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2AD12D79B for ; Wed, 6 Jul 2016 06:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.048 X-Spam-Level: X-Spam-Status: No, score=-4.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ol9wORf0I64 for ; Wed, 6 Jul 2016 06:38:28 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7985B12D5AB for ; Wed, 6 Jul 2016 06:38:28 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id u66DcRXl002615 for ; Wed, 6 Jul 2016 22:38:27 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id C222360283 for ; Wed, 6 Jul 2016 22:38:27 +0900 (JST) Received: from jcms-pop11.ecl.ntt.co.jp (jcms-pop11.ecl.ntt.co.jp [129.60.87.132]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id B54245F680 for ; Wed, 6 Jul 2016 22:38:27 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.21.83]) by jcms-pop11.ecl.ntt.co.jp (Postfix) with ESMTP id AF03F70C0BB0 for ; Wed, 6 Jul 2016 22:38:27 +0900 (JST) From: Kohei Shiomoto Message-ID: <5ffcb65a-103b-f29f-2a9f-256ce3e1932b@lab.ntt.co.jp> Date: Wed, 6 Jul 2016 22:40:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To: pce@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [Pce] Call for Papers: IFIP/IEEE IM 2017 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 13:38:31 -0000 ********************************************************************** IFIP/IEEE IM 2017 The 15th IFIP/IEEE International Symposium on Integrated Network Management 8-12 May 2017, Lisbon, Portugal http://im2015.ieee-im.org "Integrated Management in the Cloud and 5G Era" ********************************************************************** The 15th IFIP/IEEE International Symposium on Integrated Network Management (IM 2017) will be held 8-12 May 2017 in Lisbon, Portugal. Held in odd-numbered years since 1989, IM 2017 follows the 29 years tradition of NOMS and IM as the primary IEEE Communications Society forum for technical exchange on management of information and communication technology focusing on research, development, integration, standards, service provisioning, and user communities. IM 2017 will focus on the theme "Integrated Management in the Cloud and 5G Era" presenting recent, emerging approaches and technical solutions for dealing with 5G and cloud infrastructures, as well as associated services and applications. Submissions addressing traditional network management challenges are also in the scope of the conference. IM 2017 will offer five types of sessions: technical, experience, poster, panel, and dissertation. High quality will be assured through a well-qualified Technical Program Committee and rigorous peer review of papers. A special call for demonstrations is organized to allow industry partners and researchers to demonstrate early products and prototypes. CALL FOR SUBMISSIONS Technical Papers (deadline: September 4, 2016) http://im2017.ieee-im.org/call-technical-session-papers Experience Papers (deadline: September 4, 2016) http://im2017.ieee-im.org/call-experience-session-papers Demo Proposals (deadline: January 13, 2017) http://im2017.ieee-im.org/call-demos Dissertation Papers (deadline: December 1, 2016) http://im2017.ieee-im.org/call-dissertation-papers Panel Proposals (deadline: December 9, 2016) http://im2017.ieee-im.org/call-panels Tutorial Proposals (deadline: September 30, 2016) http://im2017.ieee-im.org/call-tutorials Workshop Proposals (deadline: September 9, 2016) http://im2017.ieee-im.org/call-for-workshops TOPICS OF INTEREST Authors are invited to submit papers that fall into or are related to the topic areas that are listed below. Network Management - Software-Defined Networks - IP Networks - Wireless and Cellular Networks Optical Networks - Overlay Networks - Virtual Networks - Home Networks - Access Networks - Enterprise and Campus Networks - Data Center Networks - SCADA Networks and DCS - Wireless Sensor Networks - Internet of Things Networks - Information-Centric Networks Service Management - Multimedia Services - Content Delivery Services - Cloud Computing Services - Internet Connectivity and Access - Internet of Things Services - Security Services - Context-Aware Services - Information Technology Services Business Management - Economic Aspects - Multi-Stakeholder Aspects - Service Level Agreements - Lifecycle Aspects - Process and Workflow Aspects - Legal Perspective - Regulatory Perspective - Privacy Aspects Functional Areas - Fault Management - Configuration Management - Accounting Management - Performance Management - Security Management Management Paradigms - Centralized Management - Hierarchical Management - Distributed Management - Federated Management - Autonomic and Cognitive Management - Policy-Based Management - Pro-Active Management - Energy-Aware Management - QoE-Centric Management - Intent-Based Management Technologies - Fog and Edge Computing - Communication Protocols - Middleware - Overlay Networks - Cloud Computing and Cloud Storage - Data, Information & Semantic Models - Information Visualization - Software-Defined Networking - Network Function Virtualization - Orchestration - Operations/Business Support Systems Methods - Mathematical Logic and Automated Reasoning - Mathematical Optimization - Control Theory - Probability Theory, Stochastic Processes, and Queuing Theory - Machine Learning - Evolutionary Algorithms - Economic and Game Theory - Monitoring and Measurements - Data Mining and (Big) Data Analysis - Computer Simulation Experiments - Prototype Implementation and Testbed Experimentation - Field Trials GENERAL CO-CHAIRS - Prosper Chemouil, Orange Labs, France - Edmundo Monteiro, University of Coimbra, Portugal TPC CO-CHAIRS - Marinos Charalambides, University College London, UK - Edmundo Madeira, University of Campinas, Brazil - Paulo Simoﾌテs, University of Coimbra, Portugal From nobody Wed Jul 6 17:23:49 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFEE12D150 for ; Wed, 6 Jul 2016 17:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SB7x35ribC5 for ; Wed, 6 Jul 2016 17:23:44 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4826512D126 for ; Wed, 6 Jul 2016 17:23:44 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f89so1273559qtd.2 for ; Wed, 06 Jul 2016 17:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8p0lJ5yY1XriFjsi3r3rKiQTsEAHCmIKMAOOXR3jYME=; b=JAYHJTn1NMn04x6tfUQxhQpzsmy1/yFjNPykJ1hfDomrjrIC5Cl0ZZF+FlJRRj7BnI 88GLrRPC38Ui4W4/feGlpHcHP2Ha9rmXB1VChIP3Pjgc5buRPdJ80b/7ZJOSp/xVy+Jb oVI5RG/8cVHpracSNkNaro+jK1VzJviEypQWxR9KBM+ZGSiMBeyifF80sWRS4l8m/aOZ 8E1/iMe/8EVB9vjf2XyzQFW9z7dVswSbHC8pZ/YNZlV6tPbIa8P043JQ3WKUS5kzOJSa FUaWy3sjTh99wruJ+cMD5wjJkHzWVhCnwuPhtdzuSTPODmqrTYwAcz5i7k5++DEveJyv L94g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8p0lJ5yY1XriFjsi3r3rKiQTsEAHCmIKMAOOXR3jYME=; b=mRFm9a0zaMye7IVadsM6XBahLVNGT+UQV3EaLTLUGqOA6FPyIvzUlc4U9P4D/1+iHd RDvsat8BgroItgtG+y3W3DH4zT+OoYc21Mcs7s+9G6pyonzpZNRUEEAjQTkrdziFqYsM OtOsK5P2xOmYedJSoJGeIT7SB/DnRLM9EazvZZigOMahOzrYzgHGMkiCwRa4vj8che4g Y0CB6zh3bIQLTmjsLcu5i7ZDeabskpMOFjF0iEEUxvebjQl3n6suCCXupbJKpgV9jz2o 3fsujOePyQQNNPnFqyEnOO629xq3NU1KTEsNurMiQ+ohkziq8gL6Ls/qntaSHe113ZTA IRcQ== X-Gm-Message-State: ALyK8tJMMbuDrzLGI4IVcoa0t2HrE/ymUjYyWFWzdDVFOnuwIJzVo8Krv/QMq6y2gMUOg6fYiE751phMBz7NuTDw X-Received: by 10.200.43.236 with SMTP id n41mr39782498qtn.52.1467851023291; Wed, 06 Jul 2016 17:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.53.19 with HTTP; Wed, 6 Jul 2016 17:23:42 -0700 (PDT) In-Reply-To: References: <10376B02BC561F4185654159EF79002045948CA9@szxeml561-mbx.china.huawei.com> From: Ina Minei Date: Wed, 6 Jul 2016 17:23:42 -0700 Message-ID: To: Dhruv Dhody , Venugopal Reddy K , pce Content-Type: multipart/alternative; boundary=001a11404e8ed3ff04053700b2be Archived-At: Cc: Edward Crabbe , "Robert Varga -X \(rovarga - Pantheon Technologies SRO at Cisco\)" , "Siva Sivabalan \(msiva\)" , Cyril Margaria Subject: Re: [Pce] Few queries on pce initiated lsp//FW: Few comments/queries on draft-ietf-pce-pce-initiated-lsp-04 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 00:23:48 -0000 --001a11404e8ed3ff04053700b2be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Following the reminder from Adrian, please see my replies inline below, look for ###. > > > > > > *From:* Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Venugopal Reddy = K > *Sent:* 2015=E5=B9=B46=E6=9C=8816=E6=97=A5 11:27 > *To:* pce; inaminei@google.com > *Cc:* Cyril Margaria > *Subject:* Re: [Pce] Few comments/queries on > draft-ietf-pce-pce-initiated-lsp-04 > > > > Hi, > > > > Request authors to let us know your view about it. > > > > Thanks. > > Venu > > > > *From:* Cyril Margaria [mailto:cyril.margaria@gmail.com > ] > *Sent:* 2015=E5=B9=B46=E6=9C=8810=E6=97=A5 20:34 > *To:* Venugopal Reddy K > *Cc:* pce; inaminei@google.com > *Subject:* Re: [Pce] Few comments/queries on > draft-ietf-pce-pce-initiated-lsp-04 > > > > Hi, > > > > On 10 June 2015 at 03:32, Venugopal Reddy K > wrote: > > Hi, Everyone! > > > > Have few comments/queries on draft-ietf-pce-pce-initiated-lsp-04. Could > you please clarify on below points: > > > > Section 6 > > In case of PCEP session failure, control over PCE-initiated LSPs > > reverts to the PCC at the expiration of the redelegation timeout. At > > this point, the LSP is an "orphan" until the expiration of the State > > Timeout timer. To obtain control of a PCE-initiated LSP, a PCE > > (either the original or one of its backups) sends a PCInitiate > > message, including just the SRP and LSP objects, and carrying the > > PLSP-ID of the LSP it wants to take control of > > 1. In case of Backup PCE, what is the trigger point to send > PCInitiate message to take control of orphan PCE-initiated LSP? I am > wondering how does a backup PCE come to know that some LSPs are orphaned? > > I see two scenarios : > > 1) Another PCEP Session is up , in that case it seems to imply that the > PCE(s) keep track of the LSPs it can manage and the liveliness of the oth= er > PCEs. > 2) There is no other PCEP session, the PCC reconnects to another PCE, > in this case the PCE can try to take ownership of the Initiated, not > delegated LSPs > > While I believe 1) is an interesting architecture, I do not think the > protocol procedures should put such constraint to the PCE implementation, > so the second option you propose should be allowed. > > > > Yes. Let us know authors view about it. > ### Either option is allowed. The trigger of how to detect an orphaned LSP is outside the scope of this document, similar to the decision of when to instantiate or delete a pce-intiated LSP. This document only puts forth the procedure a PCE can take after detecting an orphan LSP. Either (1) or (2) can be supported with these procedures, but note that the document does not _require_ support of any particular method for identifying orphans, and that the state will be correctly cleaned up at the expiration of the State Timeout timer. > > > 2. Another option would be, if PCC takes charge and delegate the > orphaned PCE initiated LSPs to backup PCE based on the local policy? > > > > I think this should be allowed, the text could be : > > In case of PCEP session failure, control over PCE-initiated LSPs > > reverts to the PCC at the expiration of the redelegation timeout. At > > this point, the PCC MAY delegate the LSP to another PCE. the LSP is an "o= rphan" until the expiration of the State > > Timeout timer. > > > > Some coordination between PCEs is still needed, for the original PCE to > regain control over that LSP the current PCE must forfeit control over th= at > LSP. > > In addition there is no Error to indicate to the PCE that he can't have > the delegation back, this should be added , for instance 24,4 > > LSP instantiation error, Requested delegation rejected, another PCE has t= he delegation. (ideally allow the optional inclusion of the other PCE SPEAK= ER-IDENTITY-ID for troubleshooting. it should be subject to security polici= es) > > > > Yes. I believe draft doesn=E2=80=99t address it. According to draft, PCC = cannot > revoke the delegation for PCE initiated LSPs for an active PCEP session. > So, if the original PCE is UP and had to take the control back of its own > initiated LSPs(from backup PCE), it might not be possible without some > coordination between both PCEs(either through in-band or out-of-band > mechanisms). > > Another option would be, PCC can identify the original PCE from PCE > SPEAKER-IDENTITY-ID of initiated LSP(at create time). Any time original P= CE > tries to take control, PCC may choose to either revoke control of LSP fro= m > backup PCE and delegate back to original PCE Or may send PCErr with > =E2=80=9Crequested delegation rejected=E2=80=9D. > > > > Request authors opinion about it. > ### The draft avoids this kind of local action because it creates a situation where decisions around the ownership of the LSPs are now split between the central controller (where by central controller I mean either one or multiple PCEs cooperating) and the local node, rather than being owned by the central controller. This is also why a PCC cannot revoke a delegation for a PCE-initated LSP. Allowing a mixed way of operation would bring the need for a lot of complexities and error handling. I think this is something better solved at the PCE layer. > > > > Response will be appreciated. > > > > Thanks a lot. > > > > Regards, > > Venu > > > > > > Regards, > Cyril > > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > > --001a11404e8ed3ff04053700b2be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following the reminder from Adrian, please see my replies inline below, lo= ok for ###. =C2=A0

=C2=A0

=C2=A0

From: Pce [mai= lto:pce-bounces@i= etf.org] On Behalf Of Venugopal Reddy K
Sent: 2015=E5=B9=B46=E6=9C= =8816=E6=97=A5 11:27
To: pce; in= aminei@google.com
Cc: Cyril Margaria
Subject: Re: [Pce] Few comments/queries on draft-ietf-pce-pce-initia= ted-lsp-04

=C2=A0

Hi,<= /p>

=C2=A0

Request authors to let us= know your view about it.

=C2=A0

Thanks.

Venu=

=C2=A0

From: Cyril Ma= rgaria [mailt= o:cyril.margaria@gmail.com]
Sent: 2015=E5=B9=B46=E6=9C= =8810=E6=97=A5 20:34
To: Venugopal Reddy K
Cc: pce; in= aminei@google.com
Subject: Re: [Pce] Few comments/queries on draft-ietf-pce-pce-initia= ted-lsp-04

=C2=A0

Hi,

=C2=A0

On 10 June 2015 at 03:32, Venugopal Reddy K <venugopalreddyk= @huawei.com> wrote:

Hi, Everyone!

=C2=A0

Have few comments/quer= ies on draft-ietf-pce-pce-initiated-lsp-04. Could you please clarify on bel= ow points:

=C2=A0

=
=C2=A0 Section 6=

=
=C2=A0=C2=A0In case of PCEP se=
ssion failure, control over PCE-initiated LSPs

=C2=A0=C2=A0 reverts to the PCC at the expiration of the redelegation= timeout.=C2=A0 At

=C2=A0=C2=A0 this point, the LSP is an "orphan" until the e= xpiration of the State

=C2=A0=C2=A0 Timeout timer.=C2=A0 To obtain control of a PCE-initiate= d LSP, a PCE

=C2=A0=C2=A0 (either the original or one of its backups) sends a PCInitiate

=C2=A0=C2=A0 message, including just the SRP and LSP objects, and car= rying the

=C2=A0=C2=A0 PLSP-ID of the LSP it wants to take control of=

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In case of Backup PCE, what is the tri= gger point to send PCInitiate message to take control of orphan PCE-initiat= ed LSP? I am wondering how does a backup PCE come to know that some LSPs ar= e orphaned?

I see two scenarios :

=C2=A0 1) Another PCEP Session is up , in that case = it seems to imply that the PCE(s) keep track of the LSPs it can manage and = the liveliness of the other PCEs.
=C2=A0=C2=A0 2) There is no other PCEP session, the PCC reconnects to anoth= er PCE, in this case the PCE can try to take ownership of the Initiated, no= t delegated LSPs

=C2=A0While I believe 1) is an interesting architecture, I do not think the= protocol procedures should put such constraint to the PCE implementation, = so the second option you propose should be allowed.

=C2=A0

Yes. Let us know autho= rs view about it.


### Either option is allowed.=C2=A0 The t= rigger of how to detect an orphaned LSP is outside the scope of this docume= nt, similar to the decision of when to instantiate or delete a pce-intiated= LSP. This document only puts forth the procedure a PCE can take after dete= cting an orphan LSP. Either (1) or (2) can be supported with these procedur= es, but note that the document does not _require_ support of any particular= method for identifying orphans, and that the state will be correctly clean= ed up at the expiration of the State Timeout timer.=C2=A0

=C2=A0

<= u>

=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Another option would be, if PCC takes = charge and delegate the orphaned PCE initiated LSPs to backup PCE based on = the local policy?

=C2=A0

I think this should be allowed, the text could be : = 

In case of PCEP session failure, control over PCE-initiated LSPs
reverts to the PCC at the expiration of the redelegation timeout.=C2=
=A0 At
this point, the PCC MAY delegate the LSP to another PCE. the LSP is an=
 "orphan" until the expiration of the State
Timeout timer.

=C2=A0

Some coordination bet= ween PCEs is still needed, for the original PCE to regain control over that= LSP the current PCE must forfeit control over that LSP.

In addition there is no Error to indicate to the PCE= that he can't have the delegation back, this should be added , for ins= tance 24,4 

LSP instantiation error, Requested delegation rejected, another PCE ha=
s the delegation. (ideally allow the optional inclusion of the other PCE SP=
EAKER-IDENTITY-ID for troubleshooting. it should be subject to security pol=
icies) 
=C2=A0

Yes. I believe draft d= oesn=E2=80=99t address it. According to draft, PCC cannot revoke the delega= tion for PCE initiated LSPs for an active PCEP session. So, if the original= PCE is UP and had to take the control back of its own initiated LSPs(from backup PCE), it might not be possible witho= ut some coordination between both PCEs(either through in-band or out-of-ban= d mechanisms).

Another option would b= e, PCC can identify the original PCE from PCE SPEAKER-IDENTITY-ID of initia= ted LSP(at create time). Any time original PCE tries to take control, PCC m= ay choose to either revoke control of LSP from backup PCE and delegate back to original PCE Or may send PCErr wi= th =E2=80=9Crequested delegation rejected=E2=80=9D.

=C2=A0

Request authors opinio= n about it.


### The draft avoids this kind of local action = because it creates a situation where decisions around the ownership of the = LSPs are now split between the central controller (where by central control= ler I mean either one or multiple PCEs cooperating) and the local node, rat= her than being owned by the central controller. This is also why a PCC cann= ot revoke a delegation for a PCE-initated LSP. Allowing a mixed way of oper= ation would bring the need for a lot of complexities and error handling. I = think this is something better solved at the PCE layer.=C2=A0

=

=C2=A0

=C2=A0

Response will be appreciated. <= u>

=C2=A0

Thanks a lot.

=C2=A0

Regards,

Venu

=C2=A0

=C2=A0

Regards,
=C2=A0Cyril

=C2=A0

_______________________________________________
Pce mailing list
Pce@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pce

=C2=A0



--001a11404e8ed3ff04053700b2be-- From nobody Wed Jul 6 18:26:41 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD0B12B00D; Wed, 6 Jul 2016 18:26:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707012640.26796.30023.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 18:26:40 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-association-group-01.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:26:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : PCEP Extensions for Establishing Relationships Between Sets of LSPs Authors : Ina Minei Edward Crabbe Siva Sivabalan Hariharan Ananthakrishnan Xian Zhang Yosuke Tanaka Filename : draft-ietf-pce-association-group-01.txt Pages : 13 Date : 2016-07-06 Abstract: This document introduces a generic mechanism to create a grouping of LSPs in the context of a PCE. This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and is equally applicable to the active and passive modes of a stateful PCE as well as a stateless PCE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-association-group-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-group-01 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/ From nobody Thu Jul 7 07:53:54 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE4812D0A1 for ; Thu, 7 Jul 2016 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc-7djOBpq-r for ; Thu, 7 Jul 2016 07:53:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790CD12D1B9 for ; Thu, 7 Jul 2016 07:53:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNH66325; Thu, 07 Jul 2016 14:53:47 +0000 (GMT) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jul 2016 15:53:45 +0100 Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Thu, 7 Jul 2016 20:23:35 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: Applicability of PCE to ACTN Thread-Index: AdHYXib6qpgdfwYVQ8WjRbGFC4fJaQ== Date: Thu, 7 Jul 2016 14:53:35 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C8C867C@blreml501-mbb> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.78.233] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C8C867Cblreml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.577E6CFC.0037, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 464fc9ec0123351a351bd9293f5b0312 Archived-At: Subject: [Pce] Applicability of PCE to ACTN X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:53:53 -0000 --_000_23CE718903A838468A8B325B80962F9B8C8C867Cblreml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, This is an informational draft which discuss the applicability of PCE (and = PCEP) for ACTN. It also maps how the various ongoing work in PCE WG comes t= ogether in the context of ACTN. We hope to discuss this further during the = IETF week. As usual comments on the list are most welcome. Regards, Dhruv(/Young/Daniele) Name: draft-dhody-pce-applicability-actn Title: Applicability of Path Computation Element (PCE) for Abstrac= tion and Control of TE Networks (ACTN) Status: https://datatracker.ietf.org/doc/draft-dhody-pce-applicabil= ity-actn/ Htmlized: https://tools.ietf.org/html/draft-dhody-pce-applicability-a= ctn-00 Abstract: Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network operations needed to orchestrate, control and manage large-scale multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to- end virtual service aware connectivity and network function virtualization services. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. This document examines the applicability of PCE to the ACTN framework. --_000_23CE718903A838468A8B325B80962F9B8C8C867Cblreml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

This is an informational draft which discuss the applicabili= ty of PCE (and PCEP) for ACTN. It also maps how the various ongoing work in= PCE WG comes together in the context of ACTN. We hope to discuss this further during the IETF week. As usual co= mments on the list are most welcome.

 

Regards,

Dhruv(/Young/Daniele)

 

 

 

Name:           draft-dhody-pc= e-applicability-actn
Title:          Applicability of Path Computation = Element (PCE) for Abstraction and Control of TE Networks (ACTN)
Status:         https://datatracker.ietf.org/doc/draft-dhody-pce-applicabi= lity-actn/
Htmlized:       https://tools.ietf.org/html/draft-dhody-pce-applicability-actn-00<= /span>


Abstract:
   Abstraction and Control of TE Networks (ACTN) refers to the se= t of
   virtual network operations needed to orchestrate, control and = manage
   large-scale multi-domain TE networks so as to facilitate netwo= rk
   programmability, automation, efficient resource sharing, and e= nd-to-
   end virtual service aware connectivity and network function    virtualization services.

   The Path Computation Element Communication Protocol (PCEP) pro= vides
   mechanisms for Path Computation Elements (PCEs) to perform pat= h
   computations in response to Path Computation Clients (PCCs) re= quests.

   This document examines the applicability of PCE to the ACTN    framework.

--_000_23CE718903A838468A8B325B80962F9B8C8C867Cblreml501mbb_-- From nobody Thu Jul 7 15:07:34 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 720BD12D107; Thu, 7 Jul 2016 15:07:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707220728.18821.78237.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 15:07:28 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-hierarchy-extensions-03.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 22:07:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE) Authors : Fatai Zhang Quintin Zhao Oscar Gonzalez de Dios Ramon Casellas Daniel King Filename : draft-ietf-pce-hierarchy-extensions-03.txt Pages : 25 Date : 2016-07-07 Abstract: The Hierarchical Path Computation Element (H-PCE) architecture (RFC 6805), provides a mechanism to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing necessary Hierarchical PCE procedures and protocol extensions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-hierarchy-extensions-03 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/ From nobody Thu Jul 7 18:32:05 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7912D77C; Thu, 7 Jul 2016 18:31:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708013159.18789.97557.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2016 18:31:59 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 01:31:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model Authors : Edward Crabbe Ina Minei Siva Sivabalan Robert Varga Filename : draft-ietf-pce-pce-initiated-lsp-06.txt Pages : 18 Date : 2016-07-07 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The extensions for stateful PCE provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-06 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/ From nobody Fri Jul 8 01:28:04 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE612D08E; Fri, 8 Jul 2016 01:27:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708082758.32046.9355.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 01:27:58 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-app-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:27:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : Applicability of a Stateful Path Computation Element (PCE) Authors : Xian Zhang Ina Minei Filename : draft-ietf-pce-stateful-pce-app-06.txt Pages : 25 Date : 2016-07-08 Abstract: A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-app-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-app-06 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/ From nobody Fri Jul 8 01:30:19 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D440812D1AE for ; Fri, 8 Jul 2016 01:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9uGccksODpZ for ; Fri, 8 Jul 2016 01:30:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAA212D15E for ; Fri, 8 Jul 2016 01:30:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNI58881; Fri, 08 Jul 2016 08:30:06 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Jul 2016 09:30:03 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.199]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Fri, 8 Jul 2016 16:29:53 +0800 From: "Zhangxian (Xian)" To: Jonathan Hardwick Thread-Topic: Re: [Pce] Shepherd's review of draft-ietf-pce-stateful-pce-app-05 Thread-Index: AdHY8uVSGuTzrjP7SqG9dEDLLb8ZUw== Date: Fri, 8 Jul 2016 08:29:53 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDFEC1SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.577F648F.00FE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.199, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 62ff4bae2d26a8edc76ba27a26f48647 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-stateful-pce-app-05 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 08:30:16 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDFEC1SZXEMA512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Jon, Thank you very much for the shepherd review. Like to see this draft get m= oved forward. We have updated the draft including all the changes you suggested. BTW, I h= ave done the usual idnits check and none found. (link: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-app-06). Please see my response inline: Regards, Xian [Pce] Shepherd's review of draft-ietf-pce-stateful-pce-app-05 Jonathan Hardwick Tue, 28 June 2016 11:5= 4 UTCShow header Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix= ) with ESMTP id 6937812DE34; Tue, 28 Jun 2016 04:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=3D-2.021 tagged_above=3D-999 required=3D5 tests=3D= [BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, DKIM_VALID_AU=3D-0.= 1, HTML_MESSAGE=3D0.001, RCVD_IN_DNSWL_NONE=3D-0.0001, RCVD_IN_MSPIKE_H4=3D= -0.01, RCVD_IN_MSPIKE_WL=3D-0.01, SPF_HELO_PASS=3D-0.001, SPF_PASS=3D-0.001= ] autolearn=3Dham autolearn_force=3Dno Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=3Dpass (1024-bit= key) header.d=3Dmetaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [= 127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQFxJ4CksN24; Tue, 28 J= un 2016 04:54:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr690= 121.outbound.protection.outlook.com [40.107.69.121]) (using TLSv1.2 with ci= pher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate request= ed) by ietfa.amsl.com (Postfix) with ESMTPS id BF01112DE2F; Tue, 28 Jun 201= 6 04:54:44 -0700 (PDT) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dmetaswitch.= com; s=3Dselector1; h=3DFrom:Date:Subject:Message-ID:Content-Type:MIME-Vers= ion; bh=3D3Q4SlBgVEWxkQJPu3RCEJvAOEVCy8pukTkptDMGaq2k=3D; b=3DmiJ5PtwzGr1ts= 6xkkE0FR5u6vnx56jFiu6tPlw1gljBM7VjzxD6iP6CrwWQA6Bkoqt8MZ1b5cgkYjnizXaTJN+Lf= rEgICUrHENTCUEwfZiyNEGtpr0gCp4rSSBjTZvPQjVVphZO/cU+u6XzmiwW1g6+UBSIDlZLpNdb= MpAU+9pY=3D Received: from BLUPR0201MB1908.namprd02.prod.outlook.com (10.162.239.154) b= y BLUPR0201MB1907.namprd02.prod.outlook.com (10.162.239.153) with Microsoft= SMTP Server (TLS) id 15.1.528.16; Tue, 28 Jun 2016 11:54:43 +0000 Received: from BLUPR0201MB1908.namprd02.prod.outlook.com ([10.162.239.154])= by BLUPR0201MB1908.namprd02.prod.outlook.com ([10.162.239.154]) with mapi = id 15.01.0528.014; Tue, 28 Jun 2016 11:54:43 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-stateful-pce-app@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-stateful-pce-app-05 Thread-Index: AdHOHuRE3ZUWjZCORDGhYo7AM/deNw=3D=3D Date: Tue, 28 Jun 2016 11:54:42 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=3Dnone (sender IP is ) smtp.mailfrom=3DJonathan= .Hardwick@metaswitch.com; x-originating-ip: [81.132.84.33] x-ms-office365-filtering-correlation-id: 3a50d51d-20c9-47c3-927b-08d39f4afe= 36 x-microsoft-exchange-diagnostics: 1; BLUPR0201MB1907; 6:50dv9DVq6o1Ljn/+C8d= Hekd3GO2PejrxhgzNQb5HfLGT6EeyXfWBDSFPD0ZdoqYGdIfNLJJCciy0hVYauAXhZbHRxKdSxm= DRiG1wQuuZg5ALIiZOl9NRUCBRFBbjajUUbLtuNRuffZy1TeG7Q/FOhuXepSdUHUXWZ6ylanpt2= 6/cPOaSAFzmoEeQf/6tu/CFHntNIUdRK4kanwswaglFeilkLOi0KAOcGngIXztxM2cF3jjvybj0= RckeKXw9OImUoZXne3A2bUwkve0O+r+Hw8I0zvfDNnB1qcIEuQGQoaM=3D; 5:OCc5OvQT/hhFp= sLDOoce8nmZWXlflrx6St+BZiQuXDuPBGW4PO3I5RFqInj8hZ63KS6lxsG70M2tDwtOUH5nPXBP= a0Mlik0PT7jVUrIK3wK3E+aqNPahFJDoPhuDjFF5GPEUacgJ3YqlMpD4un0mMw=3D=3D; 24:SJ= jcubgZws2O+9nlQmGqSIB2OEDNmCk8t77L6PtAKIUEfy60YxOxLf+UsLSRGCzkdmP1DELBvyczg= u+Vn6qjDiOUopPaa5hLhsj1yerh1qY=3D; 7:CiwUdJjb8CkMr9bLyTAHY4X8inuOHBQKJ16W9N= pSL5nhWGbuK5d+CFF/YBfSivD4fYqSw6G3d0Bxae/SsL+G8UEyvRAN0V/7av4pFOtE+e5hSUJiG= q2aTFjhEjL4PlbrF3mUyawHb3EajNl6/U7Liv7yCn17iNrJZlOzyup8Rx5WRdSj9ypqADNn8dpf= Tw02AonMi2wssRdqzzTBNCB3LgVLGSTG+k4nE1RtEBdGEXtmPKBogx+W8wSWPbF5r3HJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0201MB1907; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(21= 748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)= (5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR0201MB1907; BCL:0; P= CL:0; RULEID:; SRVR:BLUPR0201MB1907; x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189= 002)(199003)(66654002)(81156014)(77096005)(97736004)(8676002)(81166006)(450= 100001)(122556002)(6116002)(230783001)(586003)(76576001)(8936002)(3846002)(= 2900100001)(11100500001)(105586002)(101416001)(15975445007)(74316001)(10635= 6001)(790700001)(102836003)(99286002)(229853001)(19625215002)(2351001)(1930= 0405004)(7736002)(2501003)(5003600100003)(7696003)(5630700001)(66066001)(29= 06002)(4326007)(10400500002)(9686002)(33656002)(87936001)(92566002)(3660700= 001)(3280700002)(19580395003)(5640700001)(110136002)(189998001)(54356999)(8= 6362001)(50986999)(68736007)(5002640100001)(16236675004)(7846002); DIR:OUT;= SFP:1102; SCL:1; SRVR:BLUPR0201MB1907; H:BLUPR0201MB1908.namprd02.prod.out= look.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designa= te permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary=3D"_000_BLUPR0201MB1908D1BA38= 7A88282D2633D784220BLUPR0201MB1908_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 11:54:42.9346 (U= TC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0201MB1907 Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Shepherd's review of draft-ietf-pce-stateful-pce-app-05 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 11:54:50 -0000 Hi there I have reviewed this document as document shepherd. The document looks rea= dy to be published to me, with a few minor fixes to nits in the text, as I = have identified below. The document has expired. Please could you make the mark-ups below and ref= resh the document? Many thanks Jon Section 3 Discovery is now defined in the base stateful PCE draft. Replace reference= to [I-D.sivabalan-pce-disco-stateful] with [I-D.ietf-pce-stateful-pce]. [Xian]: ok Section 4 4.2 "loading sharing" should be "load sharing". 4.3 "synchronizations procedures" should be "synchronization procedure" 4.3 "a network nodes" should be "a network node" [Xian]: all rectified. Section 5 5.3 says: If an active stateful PCE is available, the PCE can trigger the setup/deletion of scheduled requests in a centralized manner, without modification of existing head-end behaviors, by notifying the PCCs to set up or tear down the paths. This would imply the stateful PCE was doing LSP initiation. But LSP initia= tion does not seem to be covered by this document (not mentioned in section= 3 or references) so this sentence seems misplaced. Should it be removed? [Xian]: As described in the initiation draft, it is still a kind of statefu= l PCE. So I would like to keep this sentence by introducing the PCE initiat= ion draft in Section 3 plus adding a reference to this section. Does it wor= k for you? 5.4.1 "is for a working or for protection" should be "is for a working path or fo= r protection". "report the resource by a working or protection path" should be "report the= resource as a working or protection path". "compute carry out" should be "compute" [Xian]: OK. 5.4.2 "exploited" sounds like a security breach. Instead, say "used". [Xian]: Sure. References [I-D.ietf-pce-questions] is now [RFC7399]. [I-D.ietf-ccamp-flexi-grid-fwk] is now [RFC7698]. [I-D.ietf-ccamp-wson-signal-compatibility-ospf] is now [RFC7688]. [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te] is now [RFC7580]. Remove reference to [I-D.sivabalan-pce-disco-stateful]. [Xian]: all updated. --_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDFEC1SZXEMA512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Jon,

  Thank you= very much for the shepherd review. Like to see this draft get moved forwar= d.

We have updated the draft including all the changes you suggested. = BTW, I have done the usual idnits check and none found.

(link: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-app-= 06).

  Please see my = response inline:

Regards,

Xian

[Pce] Shepherd's review of draft-ietf-pce-st= ateful-pce-app-05

Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Tue, 28 June 2016 11:54 UTCShow header

Return-Path: <Jo= nathan.Hardwick@metaswitch.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix= ) with ESMTP id 6937812DE34; Tue, 28 Jun 2016 04:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=3D-2.021 tagged_above=3D-999 required=3D5 tests=3D= [BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, DKIM_VALID_AU=3D-0.= 1, HTML_MESSAGE=3D0.001, RCVD_IN_DNSWL_NONE=3D-0.0001, RCVD_IN_MSPIKE_H4=3D= -0.01, RCVD_IN_MSPIKE_WL=3D-0.01, SPF_HELO_PASS=3D-0.001, SPF_PASS=3D-0.001] autolearn=3Dham autolearn_force=3Dno
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=3Dpass (1024-bit= key) header.d=3Dmetaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [= 127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQFxJ4CksN24; Tue, 28 J= un 2016 04:54:47 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr690= 121.outbound.protection.outlook.com [40.107.69.121]) (using TLSv1.2 with ci= pher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate request= ed) by ietfa.amsl.com (Postfix) with ESMTPS id BF01112DE2F; Tue, 28 Jun 2016 04:54:44 -0700 (PDT)
DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dmetaswitch.= com; s=3Dselector1; h=3DFrom:Date:Subject:Message-ID:Content-Type:MIME-Vers= ion; bh=3D3Q4SlBgVEWxkQJPu3RCEJvAOEVCy8pukTkptDMGaq2k=3D; b=3DmiJ5PtwzGr1ts= 6xkkE0FR5u6vnx56jFiu6tPlw1gljBM7VjzxD6iP6CrwWQA6Bkoqt8MZ1b5cgkYjnizXaTJN= 3;LfrEgICUrHENTCUEwfZiyNEGtpr0gCp4rSSBjTZvPQjVVphZO/cU+u6XzmiwW1g6+= UBSIDlZLpNdbMpAU+9pY=3D
Received: from BLUPR0201MB1908.namprd02.prod.outlook.com (10.162.239.154) b= y BLUPR0201MB1907.namprd02.prod.outlook.com (10.162.239.153) with Microsoft= SMTP Server (TLS) id 15.1.528.16; Tue, 28 Jun 2016 11:54:43 +0000
Received: from BLUPR0201MB1908.namprd02.prod.outlook.com ([10.162.239.154])= by BLUPR0201MB1908.namprd02.prod.outlook.com ([10.162.239.154]) with mapi = id 15.01.0528.014; Tue, 28 Jun 2016 11:54:43 +0000
From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: "draft-ietf-pce-stateful-pce-app@ietf.org" <draft-ietf-pce= -stateful-pce-app@ietf.org>
Thread-Topic: Shepherd's review of draft-ietf-pce-stateful-pce-app-05
Thread-Index: AdHOHuRE3ZUWjZCORDGhYo7AM/deNw=3D=3D
Date: Tue, 28 Jun 2016 11:54:42 +0000
Message-ID: <BLUPR0201MB1908D1BA387A88282D2633D784220@BLUPR0201MB1908.na= mprd02.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=3Dnone (sender IP is ) smtp.mailfrom=3DJonathan= .Hardwick@metaswitch.com;
x-originating-ip: [81.132.84.33]
x-ms-office365-filtering-correlation-id: 3a50d51d-20c9-47c3-927b-08d39f4afe= 36
x-microsoft-exchange-diagnostics: 1; BLUPR0201MB1907; 6:50dv9DVq6o1Ljn/+= ;C8dHekd3GO2PejrxhgzNQb5HfLGT6EeyXfWBDSFPD0ZdoqYGdIfNLJJCciy0hVYauAXhZbHRxK= dSxmDRiG1wQuuZg5ALIiZOl9NRUCBRFBbjajUUbLtuNRuffZy1TeG7Q/FOhuXepSdUHUXWZ6yla= npt26/cPOaSAFzmoEeQf/6tu/CFHntNIUdRK4kanwswaglFeilkLOi0KAOcGngIXztxM2cF3jjv= ybj0RckeKXw9OImUoZXne3A2bUwkve0O+r+Hw8I0zvfDNnB1qcIEuQGQoaM=3D; 5:OCc5OvQT/hhFpsLDOoce8nmZWXlflrx6St+BZiQuXDuPBGW4PO3I5RFqInj8hZ63KS6l= xsG70M2tDwtOUH5nPXBPa0Mlik0PT7jVUrIK3wK3E+aqNPahFJDoPhuDjFF5GPEUacgJ3Yq= lMpD4un0mMw=3D=3D; 24:SJjcubgZws2O+9nlQmGqSIB2OEDNmCk8t77L6PtAKIUEfy60Y= xOxLf+UsLSRGCzkdmP1DELBvyczgu+Vn6qjDiOUopPaa5hLhsj1yerh1qY=3D; 7:CiwUdJjb8CkMr9bLyTAHY4X8inuOHBQKJ16W9NpSL5nhWGbuK5d+CFF/YBfSivD4fYqS= w6G3d0Bxae/SsL+G8UEyvRAN0V/7av4pFOtE+e5hSUJiGq2aTFjhEjL4PlbrF3mUyaw= Hb3EajNl6/U7Liv7yCn17iNrJZlOzyup8Rx5WRdSj9ypqADNn8dpfTw02AonMi2wssRdqzzTBNC= B3LgVLGSTG+k4nE1RtEBdGEXtmPKBogx+W8wSWPbF5r3HJ
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0201MB1907; x-microsoft-antispam-prvs: <BLUPR0201MB19070D2A383647B3249C55DE84220@BLU= PR0201MB1907.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(21= 748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)= (5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR0201MB1907; BCL:0; P= CL:0; RULEID:; SRVR:BLUPR0201MB1907;
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189= 002)(199003)(66654002)(81156014)(77096005)(97736004)(8676002)(81166006)(450= 100001)(122556002)(6116002)(230783001)(586003)(76576001)(8936002)(3846002)(= 2900100001)(11100500001)(105586002)(101416001)(15975445007)(74316001)(10635= 6001)(790700001)(102836003)(99286002)(229853001)(19625215002)(2351001)(1930= 0405004)(7736002)(2501003)(5003600100003)(7696003)(5630700001)(66066001)(29= 06002)(4326007)(10400500002)(9686002)(33656002)(87936001)(92566002)(3660700= 001)(3280700002)(19580395003)(5640700001)(110136002)(189998001)(54356999)(8= 6362001)(50986999)(68736007)(5002640100001)(16236675004)(7846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0201MB1907; H:BLUPR0201MB1908.namprd02= .prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: metaswitch.com does not designa= te permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary=3D"_000_BLUPR0201MB1908D= 1BA387A88282D2633D784220BLUPR0201MB1908_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 11:54:42.9346 (U= TC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0201MB1907
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/puBVxgtm-pIfwxjy= fG2qMpuztqU>
Cc: "pce@ietf.org" <pce@ietf.org>
Subject: [Pce] Shepherd's review of draft-ietf-pce-stateful-pce-app-05
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mai= lto:pce-request@ietf.org?subject=3Dunsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=3Dhelp>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mail= to:pce-request@ietf.org?subject=3Dsubscribe>
X-List-Received-Date: Tue, 28 Jun 2016 11:54:50 -0000

Hi there
 
I have reviewed this document as document shepher=
d.  The document looks ready to be published to me, with a few minor f=
ixes to nits in the text, as I have identified below.

The document has expired.  Please could you =
make the mark-ups below and refresh the document?


 


Many thanks


Jon


 


 


 


Section 3


Discovery is now defined in the base stateful PCE=
 draft.  Replace reference to [I-D.sivabalan-pce-disco-stateful] with =
[I-D.ietf-pce-stateful-pce].


 


[Xian]: ok


 


Section 4


4.2 "loading sharing" should be "l=
oad sharing".


4.3 "synchronizations procedures" shoul=
d be "synchronization procedure"


4.3 "a network nodes" should be "a=
 network node"


 


[Xian]: all rectified.


 


Section 5


5.3 says:


 


   If an active stateful PCE is availab=
le, the PCE can trigger


   the setup/deletion of scheduled requ=
ests in a centralized manner,


   without modification of existing hea=
d-end behaviors, by notifying the


   PCCs to set up or tear down the path=
s.


 


This would imply the stateful PCE was doing LSP i=
nitiation.  But LSP initiation does not seem to be covered by this doc=
ument (not mentioned in section 3 or references) so this sentence seems mis=
placed.  Should it be removed?


 


[Xian]: As described in the initiation draft, it =
is still a kind of stateful PCE. So I would like to keep this sentence by i=
ntroducing the PCE initiation draft in Section 3 plus adding a reference to=
 this section. Does it work for you?


 


5.4.1


"is for a working or for protection" sh=
ould be "is for a working path or for protection".


"report the resource by a working or protect=
ion path" should be "report the resource as a working or protecti=
on path".


"compute carry out" should be "com=
pute"


 


[Xian]: OK.


 


5.4.2


"exploited" sounds like a security brea=
ch.  Instead, say "used".


 


[Xian]: Sure.


 


References


[I-D.ietf-pce-questions] is now [RFC7399].


[I-D.ietf-ccamp-flexi-grid-fwk] is now [RFC7698].=



[I-D.ietf-ccamp-wson-signal-compatibility-ospf] i=
s now [RFC7688].


[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te=
] is now [RFC7580].


Remove reference to [I-D.sivabalan-pce-disco-stat=
eful].


 


[Xian]: all updated.


 
--_000_C636AF2FA540124E9B9ACB5A6BECCE6B7DEDFEC1SZXEMA512MBSchi_-- From nobody Fri Jul 8 02:49:32 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF18412B004 for ; Fri, 8 Jul 2016 02:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9F6cUyiZveI for ; Fri, 8 Jul 2016 02:49:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247C612D115 for ; Fri, 8 Jul 2016 02:49:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSF79433; Fri, 08 Jul 2016 09:49:24 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Jul 2016 10:49:24 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 8 Jul 2016 17:49:13 +0800 From: Zhuangshunwan To: "pce@ietf.org" Thread-Topic: [PCE] Solicit comments for draft-li-pce-pcep-flowspec-01 Thread-Index: AQHR2PoA8bD0SBIah029Gfp6arwMpKAORXwA Date: Fri, 8 Jul 2016 09:49:13 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858AA1D7313@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.86.254] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.577F7725.00F6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0270db5295710a69891f7d1ce25a96e9 Archived-At: Subject: [Pce] [PCE] Solicit comments for draft-li-pce-pcep-flowspec-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 09:49:31 -0000 UENFIGdyb3VwLA0KDQpXZSBoYXZlIHRha2VuIHRoZSBjb21tZW50cyBmcm9tIHRoZSBCQSBtZWV0 aW5nIGFuZCB1cGRhdGVkIHRoZSBkb2N1bWVudCwgc29tZSBjaGFuZ2VzIGFzIGZvbGxvd3M6DQoN Ci0gIGxpbWl0cyBQQ0VQIGZsb3dzcGVjIHRvIOKAnHJlZGlyZWN0IHRvIHR1bm5lbOKAnSBvbmx5 DQotICBDbGFyaXR5IHdpdGggZW5jb2Rpbmcgb2YgQkdQIGZsb3dzcGVjIGluZm9ybWF0aW9uIGlu c2lkZSBQQ0VQVExWDQotICBBZGRpbmcgUk9VVEUtRElTVElOR1VJU0hFUiBUTFYgZnJvbSBQQ0VQ LUxTIA0KLSAgVXBkYXRpbmcgSUFOQSBzZWN0aW9uDQoNCkhvcGUgeW91IGNvdWxkIGhhdmUgaW50 ZXJlc3QgaW4gdGhpcyBkcmFmdCwgaGVscCB0byByZXZpZXcgb3IgcmVmaW5lLiBZb3UgY29tbWVu dHMgd2lsbCBiZSBhcHByZWNpYXRlZC4NCg0KVGhhbmtzICYgUmVnYXJkcywsDQpTaHVud2FuDQoN Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAx NuW5tDfmnIg45pelIDE3OjIwDQrmlLbku7bkuro6IENoZW54aWEgKEQpOyBMaXpoZW5iaW47IEN5 cmlsIE1hcmdhcmlhOyBDb2xieSBCYXJ0aDsgWmh1YW5nc2h1bndhbjsgRGhydXYgRGhvZHkNCuS4 u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1wY2UtcGNlcC1mbG93 c3BlYy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktcGNlLXBjZXAt Zmxvd3NwZWMtMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2h1bndh biBaaHVhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtbGktcGNlLXBjZXAtZmxvd3NwZWMNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlQQ0VQIEV4dGVu c2lvbiBmb3IgRmxvdyBTcGVjaWZpY2F0aW9uDQpEb2N1bWVudCBkYXRlOgkyMDE2LTA3LTA4DQpH cm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxOA0KVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saS1wY2UtcGNlcC1m bG93c3BlYy0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1saS1wY2UtcGNlcC1mbG93c3BlYy8NCkh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktcGNlLXBjZXAtZmxvd3NwZWMtMDENCkRp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGkt cGNlLXBjZXAtZmxvd3NwZWMtMDENCg0KQWJzdHJhY3Q6DQogICBEaXNzZW1pbmF0aW9uIG9mIHRo ZSB0cmFmZmljIGZsb3cgc3BlY2lmaWNhdGlvbnMgd2FzIGZpcnN0IGludHJvZHVjZWQNCiAgIGlu IHRoZSBCR1AgcHJvdG9jb2wgdmlhIFJGQyA1NTc1LiAgSW4gb3JkZXIgdG8gZGlzdHJpYnV0ZSB0 aGUgZmxvdw0KICAgc3BlY2lmaWNhdGlvbnMgZnJvbSBQQ0UgY29udHJvbGxlciB0byBuZXR3b3Jr IGRldmljZSB3aXRob3V0IEJHUA0KICAgcHJvdG9jb2wgaXQgaXMgZGVzaXJhYmxlIHRvIGV4dGVu ZCBQQ0VQIHdpdGggZmxvdyBzcGVjaWZpY2F0aW9uDQogICBpbmZvcm1hdGlvbi4NCg0KICAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzZXQgb2YgZXh0ZW5zaW9ucyB0byBQQ0VQIHRvIHN1cHBv cnQNCiAgIGRpc3NlbWluYXRpb24gb2YgZmxvdyBzcGVjaWZpY2F0aW9ucy4gIFRoZSBleHRlbnNp b25zIGluY2x1ZGUgdGhlDQogICBpbnN0YW50aWF0aW9uLCB1cGRhdGlvbiBhbmQgZGVsZXRpb24g b2YgZmxvdyBzcGVjaWZpY2F0aW9ucy4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From nobody Fri Jul 8 03:26:03 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A699012D52F for ; Fri, 8 Jul 2016 03:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSmyo2h0HfFF for ; Fri, 8 Jul 2016 03:25:58 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA23912D51A for ; Fri, 8 Jul 2016 03:25:57 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id w130so5417401lfd.2 for ; Fri, 08 Jul 2016 03:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Sss0TQjF4yQctSGXm7sXmzcF/BWbwO7cb89xL2TcyYg=; b=N7E6/J4dyk59DWj/mRj8GPEKWwXfiVqYdHYF57HlH6owpFomnYJR8bj4ZVYn9fCZYo jMHXLxLl5MCknUJNDBXl+2eUC3kC69R7IKS1/drxN6mpcyEHBWiI8rbNOsj37T/Wm3l2 8oQ5lWr6nWXEAqqThAvcn4loks7kgxqg1TTiHFbpp3P+Qc5vHrrUe+xgD1kh19hMf6Ny iTUqXUKg/2GQiF7ktJZ2OSnccaqJO1XEzuUx53klcUbuJZcT56f8t82tWkxpgKAEsi36 O3twY37VEiDaODk3N2WUuDlw2uJi8N3U2IluhsQeN/SLkmd67lXRe5cN5frBejMmk4GV Eqpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Sss0TQjF4yQctSGXm7sXmzcF/BWbwO7cb89xL2TcyYg=; b=ijPqMaQedDGP2mcsKl4vbwL7Igcugy5C1DTNnzQJ32+vP6QW3+tqRk7N2l19Rdh35I TqM20YLeoHLRqzimczy+K+4lraRn1IiVDzq839QAOXg9UpKH9P6G70+79IuIX8UDvKkl TvHXUE7DDP2hXK/w7pK3nT7DP+Z2y0FbTpgwKB2M4M4nFH2fpdr/GF5dPZVjCL3LfISe BvpRDF1YQ+6LblPTJ8A7tTqr26cX+PGC1tZnxRcKZ7iVRfYroVQoPZBdkAgXE8IQWfUM RRHcXt+qy9QDZj1mPd16+3+tVMXmvD7IvFqjjhobe7OGlqiGFGKARK8UJZCMNiQzjAQT Hq/w== X-Gm-Message-State: ALyK8tKwoxpn2e6m61uaCo8DMeLSTRrTbziUoFXkXupThS4OOSAfKfJIskxEtdaYi/GTQrcIv+flmSPgCuNifQ== X-Received: by 10.25.212.141 with SMTP id l135mr1158890lfg.69.1467973555498; Fri, 08 Jul 2016 03:25:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.29.4 with HTTP; Fri, 8 Jul 2016 03:25:54 -0700 (PDT) From: Joydeep Banerjee Date: Fri, 8 Jul 2016 15:55:54 +0530 Message-ID: To: pce@ietf.org Content-Type: multipart/alternative; boundary=001a114123ba50b4a205371d3afc Archived-At: Subject: Re: [Pce] Pce Digest, Vol 141, Issue 28 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 10:26:02 -0000 --001a114123ba50b4a205371d3afc Content-Type: text/plain; charset=UTF-8 Hello When PCUpd message does not have LSPA object (since this is optional), what would be the interpretation on PCC? In "PCEP Extensions for Stateful PCE" draft, it mentions that " An LSP Update Request MUST contain all LSP parameters that a PCE wishes to Crabbe, et al. Expires October 22, 2015 [Page 24] Internet-Draft PCEP Extensions for Stateful PCE April 2015 be set for the LSP. A PCC MAY set missing parameters from locally configured defaults." So - If some objects like LSPA is missing according to the definition, PCE does not intend to update it (thus PCC MAY apply operator defaults to the missing parameters). However, it seems stateful PCE draft also says [ PCUpd definition in Sec 6.2] is taken from RFC 5440 and "extended" by PCEP extensions. RFC 5440 says (Sec 7.11) - When absent from the PCReq message, this means that the Setup and Holding priorities are equal to 0,... Should we extend the statement for PCReq to PCUpd? In that case it contradicts Stateful PCE's way of handling missing objects. Regards, Joydeep On Wed, Jun 29, 2016 at 12:30 AM, wrote: > Send Pce mailing list submissions to > pce@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/pce > or, via email, send a message with subject or body 'help' to > pce-request@ietf.org > > You can reach the person managing the list at > pce-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pce digest..." > > > Today's Topics: > > 1. Re: Proposed text for handling stateless/router-computed to > active-stateful transitions in draft-ietf-pce-stateful-pce > (Olivier Dugeon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jun 2016 19:45:26 +0200 > From: Olivier Dugeon > To: Robert Varga , "Aissaoui, Mustapha (Nokia - CA)" > , "pce@ietf.org" , > "MEURIC > Julien IMT/OLN" > Subject: Re: [Pce] Proposed text for handling > stateless/router-computed to active-stateful transitions in > draft-ietf-pce-stateful-pce > Message-ID: <5772B7B6.20706@orange.com> > Content-Type: text/plain; charset="utf-8" > > Hello Robert, > > General comment: The proposal modifications has been written following > different interoperability tests done on different commercial solutions of > both PCE and PCC. The issue raised following these tests show that the > draft has been interpreted differently and thus, need to be consolidated > i.e. precise text when ambiguity take place. > > More detail answers below. > > Regards > > Olivier > > Le 27/06/2016 15:58, Robert Varga a ?crit : > > > > On 06/14/2016 10:41 PM, Aissaoui, Mustapha (Nokia - CA) wrote: > >> Dear all, > >> > >> As promised, Stephane, Olivier and I worked on a proposal for updating > >> draft-ietf-pce-stateful-pce to handle the transition from stateless or > >> router-computed to active-stateful operation for an LSP. More > >> specifically, We are proposing the addition of a new section 5.8.3 > >> describing extensions for the following: > >> > >> > >> > >> a. support of use of PCReq/PCRep for an LSP which does not have an > >> initial path and which the PCC intends to delegate to the PCE. The > >> proposal here is to first use the same procedure as in passive-stateful > >> mode of operation with a PCReq/PCRep followed by sending the PCRpt > message. > >> > >> > >> > >> b. passing LSP constraints when delegating an LSP which already has a > >> working path. While PCE does not need to compute a path immediately, it > >> needs to save the constraints for the next opportunity to update the > >> path. In this case, the PCRpt messages is enhanced to contains an > >> additional set of the LSP parameters such as LSPA, Metric, Bandwidth, > >> and IRO objects to report the original constraints of the LSP. > >> > >> > >> > >> We are also proposing modifications to a couple of paragraphs in > >> sections 5.8.2 and 6.1 to clarify the use of the PCRpt message and of > >> the ERO object in PCRpt respectively. > >> > >> > >> > >> We appreciate if the authors of the draft and members of this WG provide > >> feedback. > >> > >> > >> > >> Regards, > >> > >> Mustapha. > >> > >> ------------------------------ > >> > >> I. New Section 5.8.3 ? Reporting LSP Constraints on LSP > >> transition from Stateless/Router-Computed to Active Stateful Modes of > >> Operation > >> > >> > >> > >> When an LSP transitions from a stateless or router-computed mode to an > >> active stateful mode of operation and the LSP has no working path, PCC > >> MUST first reuse the same procedure defined in passive stateful mode to > >> request the initial path from PCE. > >> > >> > >> > >> This additional step is required for two reasons. First, the action of > >> delegating the LSP to a PCE using a PCRpt message is not an explicit > >> request to PCE to compute a path for the LSP. The only explicit way for > >> a PCC to request a path from PCE is to send a PCReq message as per RFC > >> 5440. > > This is an intentional side-effect of changing synchrony. Delegating an > > LSP involves the PCC losing control over timing of route computation. > Well, from an operational point of view, there is a need to take back the > control of LSP on a PCC. This new text just proposes to precise these > process. > > > >> Second, the PCRpt message does not contains the original > >> constraints of the LSP path as configured by the user on the router. The > >> PCRpt message may contain the operational or computed values of those > >> same objects in the attribute-list. For example, the hop-count Metric > >> object included in the PCRpt message will contain the computed value for > >> the current path of the LSP but will not contain the hop-count bound the > >> user may have configured on the router for this LSP. Note that since in > >> this case the LSP has no working path, it may even not include any of > >> the Metric objects in the attribute-list of the PCRpt message. > >> > >> > >> > >> To address the above situation, the PCReq message SHOULD include all the > >> objects describing the current configuration of the LSP on the PCC : > >> e.g. the relevant LSPA, Metric, Bandwidth, IRO, ? objects to convey the > >> LSP path constraints to PCE. An implementation MAY allow policies on PCC > >> to determine the configuration parameters to be sent to the PCE. The LSP > >> object MAY also be included with the D-bit (Delegate bit) set to > >> indicate to PCE that it intends to delegate this LSP. The PCE uses this > >> indication to cache the constraint in these objects in anticipation of > >> the subsequent PCRpt message which should confirm the delegation by > >> setting the D-bit in the LSP object. The PCE may clear the cached > >> information if no PCRpt message for that PLSP-ID is received within a > >> finite amount of time. > > I think this really is 'PCE policy', as this requires resources on the > > PCE side, which are shared across multiple PCCs, hence a LRU or similar > > should be allowed. > > > > I am not sure what caching the information will achieve: the PCC cannot > > rely on this information to be present, hence a subsequent PCRpt needs > > to repeat this information anyway... > When a PCC loose its session with a PCE and try to setup a new PCEP > session with a backup PCE, the later needs to know the details of the > original request. Of course its a PCE problem, but if the PCC doesn't > provide the information, how the PCE could collect them ? > > > >> When an LSP transitions from a stateless or router-computed to an active > >> stateful mode of operation and the LSP has a working path, there is no > >> need to explicitly request a path from PCE at that point in time. While > >> a PCC may decide to first use the passive stateful mode procedures as in > >> the case above, there is no requirement for doing so. As such, this > >> document defines an optional procedure by which the PCC can simply > >> report the LSP constraints to the PCE in the PCRpt message. A PCC which > >> supports this procedure MUST append an additional set of the relevant > >> objects like LSPA, Metric, Bandwidth, and IRO objects, referred to as > >> the request-list(1), in which it conveys the LSP path constraints to > PCE. > > I think we also need an indication that the PCC supports this procedure > > -- otherwise the PCE cannot discern if the information is missing (which > > would be a PCErr) or the PCC does not support it (which is okay). > Yes. Good catch. > > > >> A PCE that receives a PCRpt with the request-list should assume the > >> values contained in the request-list are the actual constraints. The > >> values in the request-list must update any corresponding value saved > >> for that PLSP-ID in the LSP database. A PCE that receives a PCRpt > >> without the request-list and that PLSP-ID has no saved constraints in > >> the LSP database should assume the values contained in the > >> attribute-list are the actual constraints. In either case, the > >> constraint values can be overridden by PCE policy. > > I am not sure I understand this part. Is this related to the PCE which > > has current control of the LSP and is triggered for things like CLI > > config changing, or is this for sake of backup PCEs? > The first case apply as depending of the implementation, it is necessary > to revoke the delegation before attempting to change CLI config on the PCC. > Once the delegation is turn on, the PCC send a new PCRpt with the updated > request-list. > The second case apply when the PCC loose the PCEP session with the primary > PCE and start establish a PCEP session with its backup PCE for which it > send PCRpt message with the reques-list. > > > > > Also, would an active PCE be able to update this information? > PCE could override the information in its LSP database, but could not > update the information on the router. PCEP is not NETCONF/YANG. I mean that > PCEP statefull configuration are stored in the ephemeral configuration of > the PCC while the config CLI remains in the static configuration. > > > >> Note (1): RFC 5440 defines the request-list in the PCReq message as the > >> above objects plus the RP and END-POINTS objects. As such we may need to > >> refer to this differently. Maybe the constraint-list. > >> > >> > >> > >> II. Modifications to last paragraph in Section 5.8.2 ? > >> Active Stateful PCE LSP Update > >> > >> > >> > >> ? > >> > >> The PCRpt message MUST NOT be used by PCC to request a path from PCE. > >> > >> Standard PCReq as defined in RFC 5440 MUST be used instead. > >> > >> A PCC MUST however NOT send to any PCE a Path Computation Request > for a > >> > >> once the LSP is delegated LSP. Should the PCC decide it wants to > issue a Path > >> > >> Computation Request on a delegated LSP, it MUST perform Delegation > >> > >> Revocation procedure first. > >> > >> ? > > The intent here is that for any particular LSP exactly one mode of > > operation (passive or active) is used and they are not intermixed -- > > exactly because of synchrony problems arising from such use. > > > > I agree with the updated text, but I also wonder if a paragraph in 5.8 > > would be more appropriate. > Up to you to place the propose text at the most suitable place in the > draft. > > > >> III. Modifications to sixth paragraph in Section 6.1 ? The > >> PCRpt Message > >> > >> ? > >> > >> The intended path, represented by the ERO object, SHOULD be included > in > >> > >> PCRpt by the PCC whenever the PCC has a valid, non-empty, ERO for the > >> LSP. > >> > >> A valid ERO can be obtained by requesting a path from the local > >> router CSPF or > >> > >> from PCE using the PCReq message before delegation as explained in > >> Section 5.8.3. > >> > >> It can also be provided by local configuration on the router. A PCC > >> MUST omit the > >> > >> ERO object otherwise. In all cases, a PCC MUST NOT send an empty ERO > >> in a PCRpt > >> > >> message to PCE. > > This would contradict the end-of-sync marker definition. > > > > This also means that every PCE implementation must support the > > router-initiated computation synchrony -- which can problematic with > > some implementation architectures. > > > > It also creates some friction with pce-initiated: the PCE is free to use > > an empty ERO in PCEInitiate and the PCC is required to mirror it back in > > PCRpt -- but this text forbids empty EROs in PCRpt... > Well I understand the point. But, an empty ERO is something very strange > for me ;-) > > Concerning the end-of-sync marker, perhaps another marker could be used > instead of an empty ERO. > > For the PCEInitiate, again, it is strange for me to deploy a PCE on a > network just to push on a PCC some tunnels without ERO. This means that > you let the PCC perform the CSPF while the PCE is build for that purpose. A > simple NMS that push CLI or Netconf/Yang configuration is sufficient for > this use case. > > > > Bye, > > Robert > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@ietf.org > > https://www.ietf.org/mailman/listinfo/pce > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > > ------------------------------ > > End of Pce Digest, Vol 141, Issue 28 > ************************************ > --001a114123ba50b4a205371d3afc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello
When PCUpd message does not have LSPA= object (since this is optional), what would be the interpretation on PCC? =

In "PCEP Extensions for Stateful PCE" draft, i= t mentions that "

An LSP Update Request MUST contain all LSP= parameters that a PCE wishes to Crabbe, et al. Expires October 22, 2015 [P= age 24] Internet-Draft PCEP Extensions for Stateful PCE April 2015=C2=A0 be= set for the LSP. A PCC MAY set missing parameters from locally configured = defaults."

So - If some objects like LSPA is mis= sing according to the definition, PCE does not intend to update it (thus PC= C=C2=A0MAY apply operator defaults to the missing parameters). However, it = seems stateful PCE draft also says <attribute-list> [ PCUpd definitio= n in Sec 6.2] is taken from RFC 5440 and "extended" by PCEP exten= sions. RFC 5440 says (Sec 7.11) -

When absent from the PCReq= message, this means that the Setup and Holding priorities are equal to 0,.= ..

Should we extend the statement for PCReq to PCUpd? = In that case it contradicts Stateful PCE's way of handling missing obje= cts.

Regards,

Joydeep



<= /font>

On Wed, Jun 29, 2016 at 12:30 AM, <pce-request@ietf.org><= /span> wrote:
Send Pce mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pce@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/li= stinfo/pce
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pce-req= uest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pce-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pce digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Proposed text for handling stateless/router-computed to=
=C2=A0 =C2=A0 =C2=A0 active-stateful transitions in draft-ietf-pce-stateful= -pce
=C2=A0 =C2=A0 =C2=A0 (Olivier Dugeon)


----------------------------------------------------------------------

Message: 1
Date: Tue, 28 Jun 2016 19:45:26 +0200
From: Olivier Dugeon <olivi= er.dugeon@orange.com>
To: Robert Varga <nite@hq.sk>, &quo= t;Aissaoui, Mustapha (Nokia - CA)"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mustapha.aissaoui@nokia.com>, "pce@ietf.org" <pce@ietf.org= >, "MEURIC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Julien IMT/OLN" <julien.meuric@orange.com>
Subject: Re: [Pce] Proposed text for handling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 stateless/router-computed to active-stateful tr= ansitions in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-pce-stateful-pce
Message-ID: <5772B7B6.20706= @orange.com>
Content-Type: text/plain; charset=3D"utf-8"

Hello Robert,

General comment: The proposal modifications has been written following diff= erent interoperability tests done on different commercial solutions of both= PCE and PCC. The issue raised following these tests show that the draft ha= s been interpreted differently and thus, need to be consolidated i.e. preci= se text when ambiguity take place.

More detail answers below.

Regards

Olivier

Le 27/06/2016 15:58, Robert Varga a ?crit :
>
> On 06/14/2016 10:41 PM, Aissaoui, Mustapha (Nokia - CA) wrote:
>> Dear all,
>>
>> As promised, Stephane, Olivier and I worked on a proposal for upda= ting
>> draft-ietf-pce-stateful-pce to handle the transition from stateles= s or
>> router-computed to active-stateful operation for an LSP. More
>> specifically, We are proposing the addition of a new section 5.8.3=
>> describing extensions for the following:
>>
>>
>>
>> a.=C2=A0 =C2=A0 =C2=A0support of use of PCReq/PCRep for an LSP whi= ch does not have an
>> initial path and which the PCC intends to delegate to the PCE. The=
>> proposal here is to first use the same procedure as in passive-sta= teful
>> mode of operation with a PCReq/PCRep followed by sending the PCRpt= message.
>>
>>
>>
>> b.=C2=A0 =C2=A0 passing LSP constraints when delegating an LSP whi= ch already has a
>> working path. While PCE does not need to compute a path immediatel= y, it
>> needs to save the constraints for the next opportunity to update t= he
>> path. In this case, the PCRpt messages is enhanced to contains an<= br> >> additional set of the LSP parameters such as LSPA, Metric, Bandwid= th,
>> and IRO objects to report the original constraints of the LSP.
>>
>>
>>
>> We are also proposing modifications to a couple of paragraphs in >> sections 5.8.2 and 6.1 to clarify the use of the PCRpt message and= of
>> the ERO object in PCRpt respectively.
>>
>>
>>
>> We appreciate if the authors of the draft and members of this WG p= rovide
>> feedback.
>>
>>
>>
>> Regards,
>>
>> Mustapha.
>>
>> ------------------------------
>>
>> I.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 New Section 5.8= .3 ? Reporting LSP Constraints on LSP
>> transition from Stateless/Router-Computed to Active Stateful Modes= of
>> Operation
>>
>>
>>
>> When an LSP transitions from a stateless or router-computed mode t= o an
>> active stateful mode of operation and the LSP has no working path,= PCC
>> MUST first reuse the same procedure defined in passive stateful mo= de to
>> request the initial path from PCE.
>>
>>
>>
>> This additional step is required for two reasons. First, the actio= n of
>> delegating the LSP to a PCE using a PCRpt message is not an explic= it
>> request to PCE to compute a path for the LSP. The only explicit wa= y for
>> a PCC to request a path from PCE is to send a PCReq message as per= RFC
>> 5440.
> This is an intentional side-effect of changing synchrony. Delegating a= n
> LSP involves the PCC losing control over timing of route computation.<= br> Well, from an operational point of view, there is a need to take back the c= ontrol of LSP on a PCC. This new text just proposes to precise these proces= s.
>
>> Second, the PCRpt message does not contains the original
>> constraints of the LSP path as configured by the user on the route= r. The
>> PCRpt message may contain the operational or computed values of th= ose
>> same objects in the attribute-list. For example, the hop-count Met= ric
>> object included in the PCRpt message will contain the computed val= ue for
>> the current path of the LSP but will not contain the hop-count bou= nd the
>> user may have configured on the router for this LSP. Note that sin= ce in
>> this case the LSP has no working path, it may even not include any= of
>> the Metric objects in the attribute-list of the PCRpt message.
>>
>>
>>
>> To address the above situation, the PCReq message SHOULD include a= ll the
>> objects describing the current configuration of the LSP on the PCC= :
>> e.g. the relevant LSPA, Metric, Bandwidth, IRO, ? objects to conve= y the
>> LSP path constraints to PCE. An implementation MAY allow policies = on PCC
>> to determine the configuration parameters to be sent to the PCE. T= he LSP
>> object MAY also be included with the D-bit (Delegate bit) set to >> indicate to PCE that it intends to delegate this LSP. The PCE uses= this
>> indication to cache the constraint in these objects in anticipatio= n of
>> the subsequent PCRpt message which should confirm the delegation b= y
>> setting the D-bit in the LSP object. The PCE may clear the cached<= br> >> information if no PCRpt message for that PLSP-ID is received withi= n a
>> finite amount of time.
> I think this really is 'PCE policy', as this requires resource= s on the
> PCE side, which are shared across multiple PCCs, hence a LRU or simila= r
> should be allowed.
>
> I am not sure what caching the information will achieve: the PCC canno= t
> rely on this information to be present, hence a subsequent PCRpt needs=
> to repeat this information anyway...
When a PCC loose its session with a PCE and try to setup a new PCEP session= with a backup PCE, the later needs to know the details of the original req= uest. Of course its a PCE problem, but if the PCC doesn't provide the i= nformation, how the PCE could collect them ?
>
>> When an LSP transitions from a stateless or router-computed to an = active
>> stateful mode of operation and=C2=A0 the LSP has a working path, t= here is no
>> need to explicitly request a path from PCE at that point in time. = While
>> a PCC may decide to first use the passive stateful mode procedures= as in
>> the case above, there is no requirement for doing so. As such, thi= s
>> document defines an optional procedure by which the PCC can simply=
>> report the LSP constraints to the PCE in the PCRpt message. A PCC = which
>> supports this procedure MUST append an additional set of the relev= ant
>> objects like LSPA, Metric, Bandwidth, and IRO objects, referred to= as
>> the request-list(1), in which it conveys the LSP path constraints = to PCE.
> I think we also need an indication that the PCC supports this procedur= e
> -- otherwise the PCE cannot discern if the information is missing (whi= ch
> would be a PCErr) or the PCC does not support it (which is okay).
Yes. Good catch.
>
>> A PCE that receives a PCRpt with the request-list should assume th= e
>> values contained in the request-list are the actual constraints. T= he
>> values in the=C2=A0 request-list must update any corresponding val= ue saved
>> for that PLSP-ID in the LSP database. A PCE that receives a PCRpt<= br> >> without the request-list and that PLSP-ID has no saved constraints= in
>> the LSP database should assume the values contained in the
>> attribute-list are the actual constraints. In either case, the
>> constraint values can be overridden by PCE policy.
> I am not sure I understand this part. Is this related to the PCE which=
> has current control of the LSP and is triggered for things like CLI > config changing, or is this for sake of backup PCEs?
The first case apply as depending of the implementation, it is necessary to= revoke the delegation before attempting to change CLI config on the PCC. O= nce the delegation is turn on, the PCC send a new PCRpt with the updated re= quest-list.
The second case apply when the PCC loose the PCEP session with the primary = PCE and start establish a PCEP session with its backup PCE for which it sen= d PCRpt message with the reques-list.

>
> Also, would an active PCE be able to update this information?
PCE could override the information in its LSP database, but could not updat= e the information on the router. PCEP is not NETCONF/YANG. I mean that PCEP= statefull configuration are stored in the ephemeral configuration of the P= CC while the config CLI=C2=A0 remains in the static configuration.
>
>> Note (1): RFC 5440 defines the request-list in the PCReq message a= s the
>> above objects plus the RP and END-POINTS objects. As such we may n= eed to
>> refer to this differently. Maybe the constraint-list.
>>
>>
>>
>> II.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Modifications t= o last paragraph in Section 5.8.2 ?
>> Active Stateful PCE LSP Update
>>
>>
>>
>> ?
>>
>>=C2=A0 =C2=A0 The PCRpt message MUST NOT be used by PCC to request = a path from PCE.
>>
>>=C2=A0 =C2=A0 Standard PCReq as defined in RFC 5440 MUST be used in= stead.
>>
>>=C2=A0 =C2=A0 A PCC MUST however NOT send to any PCE a Path Computa= tion Request for a
>>
>>=C2=A0 =C2=A0 once the LSP is delegated LSP.=C2=A0 Should the PCC d= ecide it wants to issue a Path
>>
>>=C2=A0 =C2=A0 Computation Request on a delegated LSP, it MUST perfo= rm Delegation
>>
>>=C2=A0 =C2=A0 Revocation procedure first.
>>
>> ?
> The intent here is that for any particular LSP exactly one mode of
> operation (passive or active) is used and they are not intermixed -- > exactly because of synchrony problems arising from such use.
>
> I agree with the updated text, but I also wonder if a paragraph in 5.8=
> would be more appropriate.
Up to you to place the propose text at the most suitable place in the draft= .
>
>> III.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Modifications to six= th paragraph in Section 6.1 ? The
>> PCRpt Message
>>
>> ?
>>
>>=C2=A0 =C2=A0 The intended path, represented by the ERO object, SHO= ULD be included in
>>
>>=C2=A0 =C2=A0 PCRpt by the PCC whenever the PCC has a valid, non-em= pty, ERO for the
>> LSP.
>>
>>=C2=A0 =C2=A0 A valid ERO can be obtained by requesting a path from= the local
>> router CSPF or
>>
>>=C2=A0 =C2=A0 from PCE using the PCReq message before delegation as= explained in
>> Section 5.8.3.
>>
>>=C2=A0 =C2=A0 It can also be provided by local configuration on the= router. A PCC
>> MUST omit the
>>
>>=C2=A0 =C2=A0 ERO object otherwise. In all cases, a PCC MUST NOT se= nd an empty ERO
>> in a PCRpt
>>
>>=C2=A0 =C2=A0 message to PCE.
> This would contradict the end-of-sync marker definition.
>
> This also means that every PCE implementation must support the
> router-initiated computation synchrony -- which can problematic with > some implementation architectures.
>
> It also creates some friction with pce-initiated: the PCE is free to u= se
> an empty ERO in PCEInitiate and the PCC is required to mirror it back = in
> PCRpt -- but this text forbids empty EROs in PCRpt...
Well I understand the point. But, an empty ERO is something very strange fo= r me ;-)

Concerning the end-of-sync marker, perhaps another marker could be used ins= tead of an empty ERO.

For the PCEInitiate, again, it is strange for me to deploy a PCE on a netwo= rk just to push on a PCC some tunnels without=C2=A0 ERO. This means that yo= u let the PCC perform the CSPF while the PCE is build for that purpose. A s= imple NMS that push CLI or Netconf/Yang configuration is sufficient for thi= s use case.
>
> Bye,
> Robert
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce




------------------------------

Subject: Digest Footer

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


------------------------------

End of Pce Digest, Vol 141, Issue 28
************************************

--001a114123ba50b4a205371d3afc-- From nobody Fri Jul 8 07:15:00 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2037212D5C2; Fri, 8 Jul 2016 07:15:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708141500.32184.43715.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 07:15:00 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pceps-10.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:15:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : Secure Transport for PCEP Authors : Diego R. Lopez Oscar Gonzalez de Dios Qin Wu Dhruv Dhody Filename : draft-ietf-pce-pceps-10.txt Pages : 18 Date : 2016-07-08 Abstract: The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describe the usage of Transport Layer Security (TLS) to enhance PCEP security, hence the PCEPS acronym proposed for it. The additional security mechanisms are provided by the transport protocol supporting PCEP, and therefore they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 regarding the PCEP initialization phase specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pceps-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-10 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/ From nobody Mon Jul 11 01:36:46 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916F612B05E; Mon, 11 Jul 2016 01:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzeA8qV8R72Z; Mon, 11 Jul 2016 01:36:42 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0110.outbound.protection.outlook.com [104.47.40.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7325212B054; Mon, 11 Jul 2016 01:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6AtpBxg9okJjcONveLefgRix0Mtzhu/9D7WlvwYlNrU=; b=bxgranWP0Q6H06K+kTl3C+xhGGquWug5T9Miq4D84v+hv/zSYdWkZyuTltUUukj7VtswaMA+rCIUAwevXgiY5QAPK2B1Ue9XAaWo5yYA9gxy9Mf/hsnjHNUrvZNJQxp7zJsgzOn4gBURlxjl3Mbjh+l/8XMTJlEomubwXrkztdE= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 11 Jul 2016 08:36:40 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Mon, 11 Jul 2016 08:36:40 +0000 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: PCE agenda for IETF 96 Thread-Index: AdHbTm8ZpVs16Hl4S7+5CFjg2uFKpw== Date: Mon, 11 Jul 2016 08:36:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.84.162] x-ms-office365-filtering-correlation-id: e2514c34-d966-4d1f-964c-08d3a9667b4e x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1912; 6:V9fFePjtY57NgCwohv1JS34soYNiKaNN3Tq7mmqMu2kv2GtSd74Zbd98vgMb0CKJsvQlvvw96bxLtdH0/P0fOmGqVuFFwh/aXtV7wn6JbyUC0+bQ8LgilE8Ml/7B/abvdZykHEXpiKeTqgGeOCyd+z5VJOLj7REAkIijvoPbNoOT7SVEUX13ivjUiTwwxE+CVuoFXUbtA/0HryoNc2kNfghG2mqPepA/fDNdNv8vneFkuVv1aeYeZPURG69bAnLkjmPy+3kfAOHTRe7UUSU9Lz1HKGsknhkZKttgMRNWuE0YhZWzCPf6GsSqRFWphlER; 5:J2rbeIivJzvOxh5InoAzKLF6nB7saazH2khYlA0thUHkFh3kDp3dTR0kTcvHwb9mym7uRj//252DE8ql79yES8quB2BEXAgR15HivR+1NdapRrvdn9mXYpBNotL7EpQjexht1rcnXWpHLtEYdWTY7Q==; 24:FSOww+Pkwq69ntj1BcQxTt9ratdAofvr0vDI/Dz6PCl6Mk94inAiosXKlU+pcm9GUks9SCrZl3vRe9rzAJxd4y4zKbC4D7qSqokl2DUSooc=; 7:Mwfrrlik1xnpcz5TKcW0bc//xoKQehWkRudKT+55rDzCMlX2CxxR1BudImaltOXN6G2TVdaaifvl6xXpEeJ5A00UMFn9s2jEt9DR97MSP3J6w1Hm2bSG5bo5SNZzNqA3KagF88MJUWLT8xUUFB5lOxswHdb0ma57+fWpwE0rPjLV6GZe3bGk28wdXa1QtCjeyYoe7Pbih8lEn6x7hOMGKhCnwCG75lpDZ95KOhjdMgVtJH4u4KDn/PHTO/2KSGjLoF2kfYKB6kclJXoFzRnPaw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1912; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1912; x-forefront-prvs: 00003DBFE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(8936002)(97736004)(3280700002)(122556002)(7696003)(66066001)(110136002)(7736002)(15975445007)(189998001)(16236675004)(19580395003)(2906002)(7906003)(19300405004)(11100500001)(99286002)(5002640100001)(5630700001)(2351001)(5640700001)(19617315012)(5003600100003)(7846002)(33656002)(106356001)(1730700003)(6116002)(8676002)(2501003)(81166006)(81156014)(450100001)(229853001)(74316002)(3660700001)(790700001)(105586002)(77096005)(102836003)(10400500002)(2900100001)(68736007)(586003)(92566002)(50986999)(54356999)(4326007)(87936001)(3846002)(9686002)(19625215002)(86362001)(76576001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1912; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB191033F4F981D90670BC2A7B843F0BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2016 08:36:40.7135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Archived-At: Cc: "pce-chairs@ietf.org" Subject: [Pce] PCE agenda for IETF 96 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 08:36:44 -0000 --_000_BY2PR0201MB191033F4F981D90670BC2A7B843F0BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have posted the agenda for the PCE meeting as below. https://datatracker.ietf.org/meeting/96/agenda/pce/ Please note that we have two PCE sessions. The first session is our normal= session. The second session is a joint meeting with MPLS and TEAS to disc= uss YANG models. If you are presenting (in either session) please send your slides to the ch= airs by the end of Sunday July 17. Best regards Jon, JP and Julien. --_000_BY2PR0201MB191033F4F981D90670BC2A7B843F0BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have posted the agenda for the PCE meeting as bel= ow.

https://datatracker.ietf.org/meeting/96/agenda/pce/

 

Please note that we have two PCE sessions.  The= first session is our normal session.  The second session is a joint m= eeting with MPLS and TEAS to discuss YANG models.

 

If you are presenting (in either session) please sen= d your slides to the chairs by the end of Sunday July 17.

 

Best regards

Jon, JP and Julien.

 

--_000_BY2PR0201MB191033F4F981D90670BC2A7B843F0BY2PR0201MB1910_-- From nobody Mon Jul 11 01:40:00 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7733F128874; Mon, 11 Jul 2016 01:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwVS13hUzpVq; Mon, 11 Jul 2016 01:39:54 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0136.outbound.protection.outlook.com [104.47.40.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD90A12B054; Mon, 11 Jul 2016 01:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SxZiEG/78cjXz9cpAK1rtdXnATYeW2g1ByDGu22NT7A=; b=FBB1jkBzoMFXgL6ekPmWOR81gNKBF6PI0S6RCgDcuVmfva6msrf+bj0Oo/r4/OsLYp0A4azVUwf10pHPS1vrjUUBuj8U15ahbAJyr4kUpPaW3X5wE34sfHs8ohILxGFwNb9zwI3LSzPRpyv9IIV5ZvNUWjzjqJBP/hMdPt7TfoI= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (TLS) id 15.1.523.12; Mon, 11 Jul 2016 08:39:53 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Mon, 11 Jul 2016 08:39:53 +0000 From: Jonathan Hardwick To: "mpls@ietf.org" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: MPLS/PCE/TEAS joint meeting agenda for IETF 96 Thread-Index: AdHbT29OVe46pSi8RFOa1iwHyzCejg== Date: Mon, 11 Jul 2016 08:39:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.84.162] x-ms-office365-filtering-correlation-id: 323caba4-f484-4399-9dcc-08d3a966ee40 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1912; 6:ty3YBUlmdzqUu/4IPB7IBi3qrOQwiLxAVW17+wg8D5sW4aodh5m63PD7pMLKh7lmmTBIGIAjZVjavm591AWY1twPYsnojzT5qBvhxiksnYHr+TL9O+QIONFCGA0hvVXavGfdwgS9blh7fI0GnOT4Af8WlK9SXX4aYbFgRs0+7eXx4dv+oDWpPjTQA+3tcBbGKd9TAIFu+l1+ax4a547J2+ombCNt/hE206fA1GMhRKNE6ApxYm447BurQl5+9teiUeUnUXH2tHd8bC80Rm9z8kqs+DQGUKoHaL8hvUHWzCTKPVGHicEDcptGkdy5a7zN; 5:j3Mis3pHzI8SiVWxvu9L3+vjeVpMBLYQUef0Wuf1tJRCH5Itwaz/H7fylho/OBJYxNQtE2J19aYG+HHCQDcmLVXZjnXXHabjW0LamPqDznS6INxoq2nozlgFxMDi5Q4GUsTp7mIdHw/9dhO8/2Soew==; 24:UcbS19RxXhxv7WgFX+yrte77n3Dv+Zo5uxFMa8OTvvCxMnlpjluzX/e1TzNifMuQC4lpJDEMks8pQm9Mo8HtWVtFbhBXpl8FpGUTi+ilhsA=; 7:XX0U3Ap1Y0OSU6HpBrB4+HW5hVk2rPlFVKSu8m9nTBe2n3DgI8Oo5Fvy8P66/EQVBOPotBAtl5wwk9MO6Fg/LKjsumJnmwpRjW+ME7uTMeWerejPt9rLUNoEdqKRVk7S1gJ1zl3D5IsdHhV/X/G37Iifb8DqHhoiu+FUK34IzXzbn+8CROA+TveuvXNlUDdM5beWxQyuPtO3h/BtEjY86SttSm+6Y/sdCnHn62r0hgyjIKX3iHaSFJkssEwLXRSlfFXz8cN79IYqWmIYshuhZw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1912; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1912; x-forefront-prvs: 00003DBFE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(8936002)(97736004)(3280700002)(122556002)(7696003)(66066001)(7736002)(15975445007)(189998001)(16236675004)(19580395003)(2906002)(5001770100001)(7906003)(19300405004)(11100500001)(99286002)(5002640100001)(19617315012)(5003600100003)(7846002)(33656002)(106356001)(6116002)(8676002)(2501003)(81166006)(81156014)(450100001)(229853001)(74316002)(3660700001)(790700001)(105586002)(77096005)(102836003)(10400500002)(2900100001)(68736007)(586003)(92566002)(50986999)(54356999)(4326007)(87936001)(3846002)(9686002)(19625215002)(86362001)(76576001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1912; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19108B768DA83D090786C5E8843F0BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2016 08:39:53.6280 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Archived-At: Cc: "teas-chairs@ietf.org" , "mpls-chairs@ietf.org" , "pce-chairs@ietf.org" Subject: [Pce] MPLS/PCE/TEAS joint meeting agenda for IETF 96 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 08:39:56 -0000 --_000_BY2PR0201MB19108B768DA83D090786C5E8843F0BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have posted the agenda for the joint MPLS/PCE/TEAS meeting. The agenda = is the second session at the link below. https://datatracker.ietf.org/meeting/96/agenda/pce/ If you are presenting then please send your slides to the chairs by the end= of Sunday July 17. Best regards Jon (on behalf of all chairs) --_000_BY2PR0201MB19108B768DA83D090786C5E8843F0BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have posted the agenda for the joint MPLS/PCE/TEA= S meeting.  The agenda is the second session at the link below.

https://datatracker.ietf.org/meeting/96/agenda/pce/

 

If you are presenting then please send your slides t= o the chairs by the end of Sunday July 17.

 

Best regards

Jon (on behalf of all chairs)

 

--_000_BY2PR0201MB19108B768DA83D090786C5E8843F0BY2PR0201MB1910_-- From nobody Mon Jul 11 07:14:11 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6C12D1D7; Mon, 11 Jul 2016 07:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2YWyS6fTQPr; Mon, 11 Jul 2016 07:14:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF16412D1D2; Mon, 11 Jul 2016 07:14:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNM68136; Mon, 11 Jul 2016 14:14:04 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 11 Jul 2016 15:14:01 +0100 Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Mon, 11 Jul 2016 19:43:51 +0530 From: Dhruv Dhody To: "pce@ietf.org" Thread-Topic: PCEP Yang - draft-pkd-pce-pcep-yang-06 Thread-Index: AdHbfnHQGQV0IaYSRv+A6OUoF5fvCg== Date: Mon, 11 Jul 2016 14:13:50 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C8E7A56@blreml501-mbx> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.78.228] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C8E7A56blreml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5783A9AC.0101, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8f5e1ecb88a55330df58ed906ca78cab Archived-At: Cc: "'draft-pkd-pce-pcep-yang@ietf.org'" Subject: [Pce] PCEP Yang - draft-pkd-pce-pcep-yang-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 14:14:10 -0000 --_000_23CE718903A838468A8B325B80962F9B8C8E7A56blreml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have updated the PCEP-Yang data model. The new -06 version has following changes - - Adding reference to the LSP state in the TE yang model (as discu= ssed during the last IETF) ^2 /pcep-state/entity/lsp-db/lsp/lsp-ref - Marking for PCE-Initiated LSP in the LSP-state ^2 /pcep-state/entity/lsp-db/lsp/initiation - Support for segment routing (SR) ^2 Capability and MSD - Support for authentication (TLS is pending) ^2 Key, keychain, TLS - Support for PCE based associations in LSP-DB ^2 /pcep-state/entity/lsp-db/association-list ^2 /pcep-state/entity/lsp-db/lsp/association-list Latest Yang file and Tree at - https://github.com/dhruvdhody-huawei/pcep-ya= ng Draft - https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ Diff - https://www.ietf.org/rfcdiff?url2=3Ddraft-pkd-pce-pcep-yang-06 Please continue to provide your feedback. The draft is ripe for WG adoption. Regards, Dhruv (on behalf of authors and contributors) --_000_23CE718903A838468A8B325B80962F9B8C8E7A56blreml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have updated the PCEP-Yang = data model.

 

The new -06 version has follow= ing changes –

 

= -   &= nbsp;      Adding reference to th= e LSP state in the TE yang model (as discussed during the last IETF)

²  /pcep-state/entity/lsp= -db/lsp/lsp-ref

= -   &= nbsp;      Marking for PCE-Initia= ted LSP in the LSP-state

²  /pcep-state/entity/lsp= -db/lsp/initiation

= -   &= nbsp;      Support for segment ro= uting (SR)

²  Capability and MSD

= -   &= nbsp;      Support for authentica= tion (TLS is pending)

²  Key, keychain, TLS

= -   &= nbsp;      Support for PCE based = associations in LSP-DB

²  /pcep-state/entity/lsp= -db/association-list

²  /pcep-state/entity/lsp= -db/lsp/association-list

 

Latest Yang file and Tree at - https://github.c= om/dhruvdhody-huawei/pcep-yang

 

Draft - https= ://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/<= /p>

Diff - = https://www.ietf.org/rfcdiff?url2=3Ddraft-pkd-pce-pcep-yang-06

 

Please continue to provide you= r feedback.

 

The draft is ripe for WG adopt= ion.

 

Regards,

Dhruv (on behalf of authors an= d contributors)

--_000_23CE718903A838468A8B325B80962F9B8C8E7A56blreml501mbx_-- From nobody Wed Jul 13 00:39:46 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251A012DA8B; Tue, 12 Jul 2016 16:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.889 X-Spam-Level: X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUiOtXOk7e5n; Tue, 12 Jul 2016 16:00:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CFC12D52C; Tue, 12 Jul 2016 16:00:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C2D71B80F06; Tue, 12 Jul 2016 16:00:37 -0700 (PDT) To: mahendrasingh@huawei.com, kkoushik@brocade.com, emile.stephan@orange.com, qzhao@huawei.com, daniel@olddog.co.uk, jonathan.hardwick@metaswitch.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160712230037.C2D71B80F06@rfc-editor.org> Date: Tue, 12 Jul 2016 16:00:37 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 13 Jul 2016 00:39:45 -0700 Cc: pce@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Pce] [Errata Verified] RFC7420 (4673) X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 23:00:39 -0000 The following errata report has been verified for RFC7420, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7420&eid=4673 -------------------------------------- Status: Verified Type: Technical Reported by: Mahendra Singh Negi Date Reported: 2016-04-20 Verified by: Deborah Brungard (IESG) Section: 4.1 Original Text ------------- pcePcepSessState OBJECT-TYPE SYNTAX INTEGER { tcpPending(1), openWait(2), keepWait(3), sessionUp(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the session. The set of possible states excludes the idle state since entries do not exist in this table in the idle state." ::= { pcePcepSessEntry 3 } Corrected Text -------------- pcePcepSessState OBJECT-TYPE SYNTAX INTEGER { idle(0), tcpPending(1), openWait(2), keepWait(3), sessionUp(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the session." ::= { pcePcepSessEntry 3 } Notes ----- As per security consideration, if PCE needs to allow incomming connections from only known PCCs. Source addresses of PCCs are configured on PCE. If PCEP session on PCE goes down with configured PCCs. PCE needs to raise notification pcePcepSessDown (i.e. details mentioned below). Issue is whiling sending the notification pcePcepSessDown, as session state (pcePcepSessState) defined in RFC doesn't include idle state. I suggest to include idle(0) state for pcePcepSessState. pcePcepSessDown NOTIFICATION-TYPE OBJECTS { pcePcepSessState, pcePcepSessStateLastChange } STATUS current DESCRIPTION "This notification is sent when the value of pcePcepSessState leaves the sessionUp state." ::= { pcePcepNotifications 2 } -------------------------------------- RFC7420 (draft-ietf-pce-pcep-mib-11) -------------------------------------- Title : Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module Publication Date : December 2014 Author(s) : A. Koushik, E. Stephan, Q. Zhao, D. King, J. Hardwick Category : PROPOSED STANDARD Source : Path Computation Element Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jul 18 05:49:39 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BADE12D9C7; Mon, 18 Jul 2016 05:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7bXcOrA73VS; Mon, 18 Jul 2016 05:49:36 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0094.outbound.protection.outlook.com [104.47.33.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248B912D9C4; Mon, 18 Jul 2016 05:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PEtqqP9fkxmxSrxKyiz6aq0EBD4SB4G8pKoOXGBd2NY=; b=qIIzrFj+P80KYhLRcvFse6WaarqpQlP/ObfQVGTWinP6VzcsPiGFJAJ+oXCMZgbU42CmtbJJBmrrU5JlRy87ozdj34SZfcZRaUKlZpT2w87Si43baIJ+T6vbT95hyr22AKOOBCC/3vSxfzc84PL2S4JnZMMs4bQPL/9h9UO8JS8= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) with Microsoft SMTP Server (TLS) id 15.1.528.16; Mon, 18 Jul 2016 12:49:29 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Mon, 18 Jul 2016 12:49:29 +0000 From: Jonathan Hardwick To: "pce@ietf.org" , "draft-palle-pce-stateful-pce-p2mp@ietf.org" Thread-Topic: Poll for adoption: draft-palle-pce-stateful-pce-p2mp-09 Thread-Index: AdHRXl52TzypF54zRPyvUmWL/V6z6wPlAJsg Date: Mon, 18 Jul 2016 12:49:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [46.189.28.206] x-ms-office365-filtering-correlation-id: 97ee84db-c59d-4de3-1655-08d3af09f558 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1910; 6:nR3AWjaRFGzDQOaDM/bFn9Vlzdu6NmanS4pg36ftbKEiPVwUJJoWXb4IExbGk807z4Fma/9sEXuYEaZW1NpTz6penJU7m6ZbHSr36yzmj9Pk6MRKrnEDbjVymVcwM66DGM2GI5RSs/3dXZ+YRyH8PW5kOaGSbZ/7q2tzFQYNOjsDs7URlcLALwUL0m7mM9Bo7H90F5mzTGh+oginXONYRR8hQhfCKxwsweLp9akAmQ9VjhhTS2jP1rZU+pwuy8OWP0dlxxXbkLRyjxZYrKMa7DUWqbGAMhagFvk/HFcjA9Q=; 5:aK9P3IE20IHVXzWksS8NsJ/jaxZRRKLAyrCz+EvAYMUGXAaX2Do30eyKv1Z0lS1Gq6RADGqmaIrUgQSBSweWyOQ2ColYbpfqYuFapf6zx4j4e8/NDoDPQv1RemBwP7/W09TevqWl0+4NgPdnSUduuQ==; 24:Cr0zRZso3DN0xuanvWAe+bR02aOeA3tLThSpB8tgBIOuQRaLc3wz7876Euqm0HAnRBfRbDW8GYdpBvsmDoH8Zq43Ami/IFseLAcbX9Kr9os=; 7:V8zJx/Qg1DrZLR9n0SVKhMpDwWrK5wzHfmTRvhvCLcK+fd2WSqVEEDG9FVX0DNcuQF9iyfPjeINgIuGylW/37Y+jMQ9ZLhL/k+1GQ3td8eLtyDeXRgJTXlpF1GAa+3TM+3IpJ3Qt4A073CwJegMPXwCNZWmIVLwjtccCuRcvm38obS45rdIiW5owZNb5OgrGQ/ybqffvHRH6v2g07urzz+2N/cO/5aEbXzNZuHsOhc/OQh0F67HbKZy344iL2WjS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1910; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BY2PR0201MB1910; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1910; x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(52044002)(199003)(99286002)(97736004)(92566002)(5001770100001)(33656002)(122556002)(74316002)(19300405004)(8936002)(19617315012)(790700001)(81166006)(16236675004)(4326007)(105586002)(586003)(230783001)(11100500001)(189998001)(19580405001)(76576001)(2900100001)(2906002)(87936001)(7696003)(81156014)(101416001)(54356999)(50986999)(3280700002)(66066001)(8676002)(19625215002)(19580395003)(5003600100003)(2501003)(7736002)(3660700001)(77096005)(7846002)(106356001)(15975445007)(2950100001)(102836003)(6116002)(10400500002)(3846002)(68736007)(76176999)(86362001)(5002640100001)(450100001)(7906003)(9686002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1910; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910F42AC838BD74C673ED5A84360BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2016 12:49:29.0534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1910 Archived-At: Cc: "pce-chairs@ietf.org" Subject: Re: [Pce] Poll for adoption: draft-palle-pce-stateful-pce-p2mp-09 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 12:49:38 -0000 --_000_BY2PR0201MB1910F42AC838BD74C673ED5A84360BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This poll for adoption has ended and the result is that the document will b= e adopted into the PCE WG. Authors, please publish the latest version of the draft as draft-ietf-pce-s= tateful-pce-p2mp-00. Thanks Jon From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 28 June 2016 18:59 To: pce@ietf.org Cc: draft-palle-pce-stateful-pce-p2mp@ietf.org; pce-chairs@ietf.org Subject: [Pce] Poll for adoption: draft-palle-pce-stateful-pce-p2mp-09 All, This is start of a two week poll on making draft-palle-pce-stateful-pce-p2m= p-09 a PCE working group document. This draft fills a gap in explaining ho= w stateful PCE can be applied to P2MP paths. https://datatracker.ietf.org/doc/draft-palle-pce-stateful-pce-p2mp/ Please review the draft and send an email to the list indicating "yes/suppo= rt" or "no/do not support". If indicating no, please state your reasons. = If yes, please also feel free to provide comments you'd like to see address= ed once the document is a WG document. The poll ends on Tuesday July 12. Thanks, Jon, JP and Julien --_000_BY2PR0201MB1910F42AC838BD74C673ED5A84360BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This poll for adoption= has ended and the result is that the document will be adopted into the PCE= WG.

Authors, please publis= h the latest version of the draft as draft-ietf-pce-stateful-pce-p2mp-00.

 

Thanks

Jon<= /p>

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 28 June 2016 18:59
To: pce@ietf.org
Cc: draft-palle-pce-stateful-pce-p2mp@ietf.org; pce-chairs@ietf.org<= br> Subject: [Pce] Poll for adoption: draft-palle-pce-stateful-pce-p2mp-= 09

 

All,

 

This is start of a two week poll on making draft-= palle-pce-stateful-pce-p2mp-09 a PCE working group document.  This dra= ft fills a gap in explaining how stateful PCE can be applied to P2MP paths.=

https://datatracker.ietf.org/doc/draft-palle= -pce-stateful-pce-p2mp/

 

Please review the draft and send an email to the = list indicating “yes/support” or “no/do not support”= ;.  If indicating no, please state your reasons.  If yes, please = also feel free to provide comments you'd like to see addressed once the document is a WG document.

 

The poll ends on Tuesday July 12.

 

Thanks,

Jon, JP and Julien

 

 

--_000_BY2PR0201MB1910F42AC838BD74C673ED5A84360BY2PR0201MB1910_-- From nobody Mon Jul 18 07:08:43 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C8D12DDFE; Mon, 18 Jul 2016 07:08:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718140841.24882.8727.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 07:08:41 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-p2mp-00.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 14:08:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths Authors : Udayasree Palle Dhruv Dhody Yosuke Tanaka Zafar Ali Vishnu Pavan Beeram Filename : draft-ietf-pce-stateful-pce-p2mp-00.txt Pages : 32 Date : 2016-07-18 Abstract: The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE LSPs. This document provides extensions required for Path Computation Element communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-p2mp-00 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/ From nobody Mon Jul 18 09:28:28 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEB212DAF5; Mon, 18 Jul 2016 09:28:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718162813.18109.66032.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 09:28:13 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 16:28:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model Authors : Edward Crabbe Ina Minei Siva Sivabalan Robert Varga Filename : draft-ietf-pce-pce-initiated-lsp-07.txt Pages : 18 Date : 2016-07-18 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The extensions for stateful PCE provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pce-initiated-lsp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-07 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/ From nobody Mon Jul 18 09:37:49 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4642F12DADF; Mon, 18 Jul 2016 09:37:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718163748.18059.50582.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 09:37:48 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-15.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 16:37:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : PCEP Extensions for Stateful PCE Authors : Edward Crabbe Ina Minei Jan Medved Robert Varga Filename : draft-ietf-pce-stateful-pce-15.txt Pages : 51 Date : 2016-07-18 Abstract: The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-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/ From nobody Mon Jul 18 13:21:12 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2300112D0A9; Mon, 18 Jul 2016 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD5AghoLNfNW; Mon, 18 Jul 2016 13:21:08 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0101.outbound.protection.outlook.com [104.47.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BE012B043; Mon, 18 Jul 2016 13:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uJEQ60fZgaNXsx8Vc7xabXkHHfRm+qlgrKgMvaQIGIc=; b=ER9Es6+Mjv5VWQyrdSJQB5OeVDSl0GD0/QvR60hnxCcyUsawq+RYzI7Ej7pRZjiM9X3hbU+teLzzlPV1KxpwiZbiFoWYtJ8usYGDH5UeI+0EuU4VnXzEqh2JH6iUd+cWb9hpYLbnqlKQ5Y7bmpN3g2OTfZQs7zIbDupryrTJAEE= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) with Microsoft SMTP Server (TLS) id 15.1.528.16; Mon, 18 Jul 2016 20:21:06 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Mon, 18 Jul 2016 20:21:06 +0000 From: Jonathan Hardwick To: Robert Varga , Ina Minei Thread-Topic: IANA allocation for draft-ietf-pce-stateful-pce and draft-ietf-pce-pce-initiated-lsp Thread-Index: AdHQd/VpjV6zgN2LRACoMPN0CE8QhQQucRPQ Date: Mon, 18 Jul 2016 20:21:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [46.189.28.178] x-ms-office365-filtering-correlation-id: 49e4f197-e16f-4afc-859a-08d3af490c57 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1910; 6:sEEbAkbW6zT/4Kn3Ml8kaW/QfHerzEKXgD9kQ7BGhHOuJU9fv6oq30O8sHzVihYoRIviuwRkOOxwluTzZNzBo372yam8xS5hvW2raOglqos0zUfnQrW9jNdBulUEbAIzbsT922eo756n4PNeYADxHIC/6U/vDPWxIkY/Y7Hv6TU7rxoWzfkMwrjQHZR3du5X9pCceoz5KAqBd6WRj4yun0s1n9NnTx/PBPF9ZmXBp4+xYCGj1WOVAaJLifeevkgrWHAz7aHOutZC+Qu+vtQQWbQ5KCgwMbnRBP/8/XBhuz4=; 5:8qmT3rb9pHLYmRyAKVZ6JYDnkZaE6g7i4bT09gX/fCcKn65cMFyRMUH0UVolXelnqIruCOpvja8mQpQZWZ4N9AAo//dfJFXfJyfgBJ4B0HaMmHGMaD72pyLB7aO+/24AhHQu5QM3SRvhaMt0x8dYTg==; 24:Fo1jJKyJ8Zgdjp62FsBq+hzA4v8gvqGdHI7Ltj8sFzwn4WM6lcSHKwWeoA1lIUF4QLMvYDGywnAisTFbcM/IfAWEGlFjNBlx7nCDldHqPJk=; 7:iF84nO5btPhWLd0xV9SFQWs69goy+7J6eW/l7OS8s2QE/UkoRUo8Niw8fYaU9KsHDybGj1fVu3iLYbEVXml5J4QMAS/5nK9VGQw+a4upghs2LHGFzS0ST5FPUq1ZoG4C9bm0W/5M8kH36xb+pCF8KJE/fzbNpL5RPyB4ZdzqFExNGet/JmsQPpsk2sPlhKn5kDn2sLLnJzvOkKoa2Qjr1Y/KMHcgGMb4VA1kaDWwY/kEH5YdHWo6STQkUnSgWbOD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1910; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1910; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1910; x-forefront-prvs: 00073DB75F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(377454003)(199003)(24454002)(97736004)(5001770100001)(99286002)(33656002)(92566002)(122556002)(74316002)(8936002)(81166006)(4326007)(2900100001)(586003)(105586002)(11100500001)(189998001)(19580405001)(76576001)(2906002)(7696003)(305945005)(81156014)(101416001)(87936001)(54356999)(230783001)(50986999)(66066001)(8676002)(5003600100003)(19580395003)(3280700002)(7736002)(3660700001)(77096005)(7846002)(6116002)(102836003)(106356001)(10400500002)(68736007)(76176999)(86362001)(3846002)(5002640100001)(9686002)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1910; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2016 20:21:06.1085 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1910 Archived-At: Cc: "pce@ietf.org" , "pce-chairs@ietf.org" Subject: Re: [Pce] IANA allocation for draft-ietf-pce-stateful-pce and draft-ietf-pce-pce-initiated-lsp X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 20:21:11 -0000 Ina, Robert, The latest versions of draft-ietf-pce-stateful-pce and draft-ietf-pce-pce-i= nitiated-lsp posted today have addressed my comments below, so I'll start t= he process for early code point allocation now. Thanks Jon -----Original Message----- From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]=20 Sent: 27 June 2016 16:05 To: Robert Varga Cc: pce@ietf.org; pce-chairs@ietf.org Subject: IANA allocation for draft-ietf-pce-stateful-pce and draft-ietf-pce= -pce-initiated-lsp (changing the subject to match the topic) Hi Robert Thanks for this. I believe that a few fixes are needed to the IANA section= s of draft-ietf-pce-stateful-pce and draft-ietf-pce-pce-initiated-lsp to cl= arify the instructions that we are giving to IANA. Please could you make t= hese fixes so that I can kick off the allocation request? In case you have= not much time to work on these documents, don't worry - the changes are sm= all (but important) and in each case I have proposed what I believe to be t= he correct text below. If you have any concerns, please let me know. Thanks Jon =3D=3D draft-ietf-pce-stateful-pce =3D=3D Section 8.1 Please replace the text before the table with the following: IANA is requested to allocate new bits in the OSPF Parameters "PCE Capabil= ity Flags" registry, as follows. Section 8.2 Please replace the text before the table with the following: IANA is requested to allocate new message types within the "PCEP Messages"= sub-registry of the PCEP Numbers registry, as follows. Section 8.3 Please replace the text before the table with the following: IANA is requested to allocate new object-class values and object types wit= hin the "PCEP Objects" sub-registry of the PCEP Numbers registry, as follow= s. The format of the table in this section needs to be cleaned up. Copy the f= ormat from any RFC that defines a new PCEP object type. Section 8.5 Please replace the text before the table with the following: IANA is requested to allocate new Error Types and Error Values within the = " PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Number= s registry, as follows. Section 8.6 Please replace the text before the table with the following: IANA is requested to allocate new Notification Types and Notification Valu= es within the "Notification Object" sub-registry of the PCEP Numbers regist= ry, as follows. Section 8.7 Please replace the text before the table with the following: IANA is requested to allocate new TLV Type Indicator values within the " P= CEP TLV Type Indicators" sub-registry of the PCEP Numbers registry, as foll= ows. Section 8.9 Please update the text to explain the procedure for assigning new values, a= nd the qualities to track for each entry in the registry. I think you need= to add the following sentences to the end of the text before the table. New values are to be assigned by Standards Action [RFC5226]. Each value should be tracked with the following qualities: o Value o Description o Defining RFC The following values are defined in this document: =3D=3D draft-ietf-pce-pce-initiated-lsp =3D=3D Section 8.1 Please replace the text before the table with the following: IANA is requested to allocate a new message type within the "PCEP Messages= " sub-registry of the PCEP Numbers registry, as follows. Section 8.2 Please replace the text before the table with the following [I-D.ietf-pce-stateful-pce] defines the LSP Object and requests that IANA = creates a registry to manage the value of the LSP Object's Flag field. IAN= A is requested to allocate a new bit in the LSP Object Flag Field registry,= as follows. Section 8.3 Since [I-D.ietf-pce-stateful-pce] does not create a registry for the SRP ob= ject flags field, this document must do it instead. Please replace the tex= t in this section with the following. This document requests that a new sub-registry, named "SRP Object Flag Field", is created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the SRP object. New values are to be assigned by Standards Action [RFC5226]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Description o Defining RFC The following values are defined in this document: Bit Description Reference 31 LSP-Remove This document Section 8.4 Please replace the text before the table with the following [I-D.ietf-pce-stateful-pce] defines the STATEFUL-PCE-CAPABILITY TLV and re= quests that IANA creates a registry to manage the value of the STATEFUL-PCE= -CAPABILITY TLV's Flag field. IANA is requested to allocate a new bit in t= he STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows. Section 8.5 Please replace the text before the table with the following IANA is requested to allocate new error types and error values within the = " PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Number= s registry, as follows. -----Original Message----- From: Robert Varga [mailto:nite@hq.sk] Sent: 27 June 2016 13:11 To: Jonathan Hardwick Cc: DIEGO LOPEZ GARCIA ; pce@ietf.org Subject: Re: [Pce] draft-ietf-pce-pceps-07 available On 02/02/2016 04:21 PM, Jonathan Hardwick wrote: > Hi Robert Hello Jon. sorry for the delay, PCE work has been on the back burner :-( > (I'm answering as WG chair.) >=20 > =20 >=20 > Sorry for the slow reply. I would expect the progress of=20 > draft-ietf-pce-pceps through to RFC to be reasonably fast, so I'm not=20 > sure early code point allocation should be needed. The main risk=20 > would be a conflict with the stateful PCE drafts, should the new=20 > message in the PCEPS draft be allocated a clashing code point with the=20 > values that the stateful drafts have "recommended" for their messages. I agree. > I think it is possible that PCEPS will leap-frog stateful PCE on the=20 > way to RFC, so I think the best way to proceed is to obtain an early=20 > allocation for draft-ietf-pce-stateful-pce and=20 > draft-ietf-pce-pce-initiated-lsp. To do this we would only require=20 > help from the stateful draft authors (e.g. you) to answer any=20 > questions that IANA has about your text (which would happen sooner or=20 > later anyway :-). Would you like us to start an early allocation for the= se drafts? I think this is a fair assessment. I can answer any questions and an early = allocation would be an excellent way of ensuring we do not get clashes. Thanks, Robert From nobody Wed Jul 20 14:03:31 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 063C312D7E1; Wed, 20 Jul 2016 14:03:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160720210324.26404.25506.idtracker@ietfa.amsl.com> Date: Wed, 20 Jul 2016 14:03:24 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-inter-area-as-applicability-06.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 21:03:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element of the IETF. Title : Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering Authors : Daniel King Julien Meuric Olivier Dugeon Quintin Zhao Dhruv Dhody Oscar Gonzalez de Dios Filename : draft-ietf-pce-inter-area-as-applicability-06.txt Pages : 26 Date : 2016-07-20 Abstract: The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-inter-area-as-applicability-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-inter-area-as-applicability-06 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/ From nobody Thu Jul 21 09:00:20 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A312D77E for ; Thu, 21 Jul 2016 09:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.507 X-Spam-Level: X-Spam-Status: No, score=-4.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POmoQ5_bgByG for ; Thu, 21 Jul 2016 09:00:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C5512D782 for ; Thu, 21 Jul 2016 09:00:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COC19932; Thu, 21 Jul 2016 16:00:09 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Jul 2016 16:58:51 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 21 Jul 2016 08:58:45 -0700 From: Leeyoung To: "pce@ietf.org" Thread-Topic: stateful-HPCE Thread-Index: AdHjaMHG+VCCQyZ0TtaiffDL8lvYEQ== Date: Thu, 21 Jul 2016 15:58:45 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172A8AC8E3@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.160] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172A8AC8E3dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5790F189.00C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d2cfd80e096323bde0f88dfddde57c6c Archived-At: Subject: [Pce] stateful-HPCE X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 16:00:18 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E172A8AC8E3dfweml501mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi PCE WG, https://datatracker.ietf.org/doc/draft-dhodylee-pce-stateful-hpce/ We'd like to solicit WG's comment on this draft. As Dhruv presented today i= n the PCE WG meeting, this draft does not add any new protocol work. It is = informational only and the co-authors believe this draft can move to the ne= xt step. Thanks in advance for your comments, suggestions, etc for this draft. Young (on behalf of co-authors and contributors). --_000_7AEB3D6833318045B4AE71C2C87E8E172A8AC8E3dfweml501mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi PCE WG,

 

https://datatracker.ietf.org/doc/draft-dhodylee-= pce-stateful-hpce/

 

We’d like to solicit WG’s comment on thi= s draft. As Dhruv presented today in the PCE WG meeting, this draft does no= t add any new protocol work. It is informational only and the co-authors be= lieve this draft can move to the next step.

 

Thanks in advance for your comments, suggestions, et= c for this draft.

 

Young (on behalf of co-authors and contributors).

--_000_7AEB3D6833318045B4AE71C2C87E8E172A8AC8E3dfweml501mbx_-- From nobody Tue Jul 26 06:26:48 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF9F12DB3E; Tue, 26 Jul 2016 06:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMTCC9kT9Aub; Tue, 26 Jul 2016 06:26:42 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0110.outbound.protection.outlook.com [104.47.38.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A3212DB3C; Tue, 26 Jul 2016 06:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ASaOJtcQcCr/um9eOV3GSi9bMSw8SFWUod1Rm6TFwX8=; b=Sr5f07g4nW6WdJ12dUSB0DUHZC2atkl7RDec4gzs0xveGtDQjHjXKDFRe08EpHcCBJWhYIag01WQmWFjq2Y9pOqQdKhUOqY6y7eugoZDkd3OBm1OcFEb829IykxI9Hw1dWVOfQJdX9CP2Q7+CPgKoDMXXfNKToH0SfXM4g0XJAU= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 26 Jul 2016 13:11:27 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Tue, 26 Jul 2016 13:11:27 +0000 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: PCE WG meeting minutes available Thread-Index: AdHnPuRURq1ssX93RrCtl49Gg6ek7Q== Date: Tue, 26 Jul 2016 13:11:26 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.85.254] x-ms-office365-filtering-correlation-id: d2e59d3d-c8c4-49f4-072e-08d3b5565a10 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 6:ZJkcM8yDF4YJEQ8EfaHN+eaPPMT9J1crY9iqb+yCOOCJpAThyJ9aosj7zBV7j8eCLu3inbi4ZnLyeoBV0dPxY7SRXpTasbksuin7fKvVEft25uGwlg9ORPMFEd7XwOjQrzGQwFjwy95/MZWnvxmqO2ZmUyBgI2ra29z7AwYUr3TgU6TMCADnODfgDUqRb81SETrUoPBovec6GDj9wF/rtYIs1Txuh4Y6Vw2K22ToF0Ykf8feZ5EMhWQ4MMUkxK9qGC9m+WxXgDYIaDFZpKoREp1IlF0hCssxaDCo6D67dTE=; 5:LwMRE5qhx9ExW2jRHn+jNzxKid17vhztKwEb5K4gCx4O+ZBRoB+krOYiCYDXTaKPKf1qp9FcNV4tbnghAS4FpHlXALXCqB85KKhJ71eNzvpq3a7JYuyYd5BRrorQLWpa3R5u3jsCb+6y8gP3+0HIJQ==; 24:mxt4e0F0gxVAGb00iVc3beYFWLOqJR3dfqusyzJGiFBHbW3ij8vYjlWtT14Kb68xnvzRVVkQVzTuRRfNv4mEWhqWMHBQMmnoSkHijUe93Ys=; 7:YNPuwCFpoNrNk9rXwlVNdg/6i3Gm+Mvhb1bhm0bq+NotaNpWWPrthRru4BpLI6yW0gnxHnis1SpZC49XexB3BGL4IPRwk6X1kntqkubUDsyIBYM3u8tG30rEXQ91wzKdZ3SLPqUafz62wlNQq86dEA+KcEXjgmQtLl5BAn6ywCEXCLStuIIGQy2lYBiNKXqmFgc77M2XDczsPWFQ3WzxjsYGmloCqyrYtfoo+xXmV+vVDlKtmBOrGbNKNvWjjEQe x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1909; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(97927398514766)(100405760836317)(95692535739014)(18271650672692)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(54164003)(37854004)(189002)(57704003)(199003)(77096005)(5003600100003)(7906003)(74316002)(2900100001)(16236675004)(19617315012)(105586002)(15975445007)(86362001)(5002640100001)(110136002)(3846002)(97736004)(5640700001)(66066001)(106356001)(122556002)(101416001)(99286002)(76576001)(1730700003)(4326007)(7696003)(92566002)(7736002)(87936001)(81166006)(790700001)(7846002)(5630700001)(2501003)(81156014)(102836003)(6116002)(19300405004)(561944003)(10400500002)(3280700002)(8676002)(2351001)(586003)(9686002)(19580395003)(68736007)(19625215002)(2906002)(54356999)(3660700001)(11100500001)(229853001)(8936002)(450100001)(33656002)(189998001)(50986999)(19580405001)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910B13CC46AECC082AF5ACC840E0BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 13:11:26.7912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909 Archived-At: Cc: "pce-chairs@ietf.org" Subject: [Pce] PCE WG meeting minutes available X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:26:47 -0000 --_000_BY2PR0201MB1910B13CC46AECC082AF5ACC840E0BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes for the PCE meeting at IETF 96 are now available. Thanks= to all our minute takers! Please let me know if you have any comments or = corrections. https://www.ietf.org/proceedings/96/minutes/minutes-96-pce Best regards Jon =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D PCE Working Group Meeting IETF 96 (Berlin) Working Group Chairs: Julien Meuric (julien.meuric@orange.com) JP Vasseur (jpv@cisco.com) Jonathan Hardwick (jonathan.hardwick@metaswitch.com) Working Group Secretary: Daniel King (daniel@olddog.co.uk) Responsible AD: Deborah Brungard (db3546@att.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ---------------------------------------------------------------------------= ---- Session I Time: July 21, 2016, 14:00-16:00 (2:00pm-4:00pm) Location: Tiergarten, Intercontinental Berlin, Germany ---------------------------------------------------------------------------= ---- 1. Introduction --------------- 1.1. Administrivia, Agenda Bashing (chairs, 5 min) (14:00-14:05) 1.2. WG Status (chairs, 15 min) (14:05-14:20) Jeff: after fixing the semantics of MSD, we are ready to go Dhruv: The authors dicussed the intended status and felt that due to the implementation maturity and number of them, we could change from "Experimental" to "Standards Track". Xian: Authors have addressed shepherd review comments. Xian: Basically ready, but would need WG to provide more feedback. 2. Work in Progress ------------------- 2.1 PCEP Hierarchy Extensions https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ Dan King, 5 min (14:20-14:25) No questions. Julien: Regarding moving to standards track, No strong opinion, esp because= of multiple implementation. Will take it to the list. 2.2 Inter-area and Inter-AS Applicability https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability= / Dan King, 5 min (14:25-14:30) No questions. Jon: Will move to LC, after the meeting. 2.3 PCEP Enhanced Errors https://datatracker.ietf.org/doc/draft-ietf-pce-enhanced-errors/ Xian Zhang, 10 min (14:30-14:40) Dhruv: When this work was presented (IETF 78) some of the procedures and corrosponding errors and notifications have evolved. The ways in whi= ch people are thinking of deploying PCEs are not necessarily the same. People think more now of deploying hierarchical PCE. I am not sure = this document is applicable any more. We will need to review this documen= t again to ensure it reflects this. Xian: I would like to discuss with Dhruv offline to review these issues. Julien: [at mic, chair hat off] yes, ideas have moved on but this does not = make the older ideas invalid. We can update to include newer work. Jeff: Yes, it would be good to have some guidelines for the new work, as we have new mechanisms that need to be reflected Jon: Please see the action for someone to contribute text for the Security = and Operational considerations section. 2.4 BGP-based PCE Discovery Mechanism https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/ Jie Dong, 10 min (14:40-14:50) Poll - Who has read this document? [About 12] - Who would like to see this become a WG document? [Slightly fewer] 3. New Work ----------- 3.1 PCEP Experimental Code Points https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/ Dhruv Dhody, 10 min (14:50-15:00) Adrian: Do this, but. Its not quite right yet. We will need to tweak the proposal. Experiments are good, and if the ranges are kept small th= ey force developers to an early request for a code point or let go. If= a code point is used for an experiment and the open source platform t= hen release the version, it might mean the projct code point squats. Dhruv: Could we assign for a specific time period, 1,3,5 years? Adrian: Sounds like early allocation. I think we need to think about a thir= d way. Lou: Respond to Adrian's point, there is a allocation policy, maybe they wa= nt to use a code point for a 1-2 years. Its a "specification required". Dhruv: When I read the allocation policy document, it was not clear that wa= s possible. Lou: You can also use a "Reserved" method. [See RFC5226?] Adrian: This does not exist. It never did. Lou: What you're describing is not "experimentation". Experiments are isol= ated - you should not coordinate code points between experiments. That is = an IANA function. Use IANA if that is what you want to do. Lou: I am also concerned about informal allocation of code points across multiple protocols. Dhruv: No, will exclude other/multiple protocols. Julien: [Pesonal view] Thats why I like focusing on the essentials. Just t= he message, object and TLV code point spaces. Jon: I would like to see an experiment registry. Given the IANA sections of= a number of I-Ds I have recently reviewed, I would also like to add experimental ranges for error-types and notfications. Michael: We had a similar problem in TCPM, please look at RFC6994 as it mig= ht address some of the issues you highlight here. Poll - Who read the I-D? [A handful] - WHo think this is a good base for the discussion? [Similar amount] 3.2 Applicability of PCEP to ACTN https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/ Dhruv Dhody, 10 min (15:00-15:10) Jon: Yes, it is my fault that you have had to write this I-D. Its helped me= to understand the context of ACTN. The PNC <-> MSDC is hierachical PCE. T= he VN Association is not clear as to why the PNCs need to know the VN inf= o, its seems the VN Association info would be used for the MSDC and above= . Finally, is PCEP-LS integral to ACTN? Dhruv: If you want to use other protocols with ACTN, thats fine. PCEP-LS is= not mandated. Jon: Good, so its not fundemental. Is PCECC something that needs to be in t= his applicability document? Dhruv: The relationship with PCECC and ACTN is such that PCECC is just one = PNC, and another PNC could be using SR or RSVP-TE. I will describe the relationship in the document as well. Jeff: With PCEP-LS you are creating complexity and capability that already exists with things like BGP-LS. Dhruv: It depends how you want to use it, if you use PCECC and you have PCE= P already you can pull TE info via PCEP-LS and not have to use BGP-LS. There are extremes. Jeff: You will still be missing link attributes. Julien: You should focus on how PCEP-LS may be used for ACTN. Pawel Brzozowski: Besides IGPs and BGP-LS we also have YANG. We also have = Ross telling us not to create many ways to do a single thing. = We don't need another mechanism. 3.3 Hierarchical PCE Discovery https://datatracker.ietf.org/doc/draft-chen-pce-h-discovery/ Huaimo Chen, 10 min (15:10-15:20) Julien: Does the Parent PCE really need to discover further information abo= ut the Child PCE, if I have already manually configured this info (capability and reachability). Huaimo: We need to confirm the configration in the protocol. Julien: It is not discovery, it is a configuration check. Is this informat= ion dynamic? Huaimo: There are security consideration, which is why configuration must b= e validated. 3.4 Connections and Accesses for Hierarchical PCE https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/ Huaimo Chen, 10 min (15:20-15:30) Adrian: Your identified requirements mentioned H-PCE architecture (RFC6805)= , but I think there are methods available for discovery and dissemina= tion of inter-domain links. These requirements might be solved by things like BGP-LS. Depending the deployment and configuration policy, you= may find the operator will already know which links exist between domai= ns. Huaimo: Some times they dont, here we provide a easy way to provide that information. Igor: What if there is no link between domains, how does the parent PCE com= pute a inter-domain path? Huaimo: Bad luck. Igor: If I report (parent PCE) I cannot compute a path, how do I handle thi= s? Anton Ivamnov: We have BGP-LS, this should be closed. Julien: The usecase is the same, you are duplicating the work already done. 3.5 Native PCE TED https://datatracker.ietf.org/doc/draft-chen-pce-pcc-ted/ Huaimo Chen, 10 min (15:30-15:40) Adrian: The first slide is misleading, what you have is a partial diagram f= rom RFC 4655. You want to extend this to a node not running a routing protocol and using PCEP to learn TED. Huaimo: Yes. ---------------------------------------------------------------------------= ---- Session II Joint YANG session with MPLS & TEAS & PCE Time: July 21, 2016, 16:20-18:20 (4:20pm-6:20pm) Location: Charlottenburg II/III, Intercontinental Berlin, Germany ---------------------------------------------------------------------------= ---- Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pa= van and Jon taken by Lou and George. 1. Introduction --------------- 1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30) 2. YANG models discussion ------------------------- 2.1 YANG Data Model for TE Topologies https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ Xufeng Liu, 20 min (16:30-16:50) Dhruv Dhody: Relationship with SR model? XL: Types to be shared. DD: Do we need RW on per-node attributes? Tarek: There are cases where information is learned via IGP, but other case= s where static may be supported, thus the need for RW DD: What do we do on conflicts? TBD Igor Bryskin: one of the clients (users?) wanted to do path computation bas= ed on TE information as well Pavan: How many have read? Not so many. Please read and send comments to th= e list. 2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ Tarek Saad, 20 min (16:50-17:10) Lou Berger: Send that [option request] to Netmod. Xian Zhang: No strong preference among options, but, do these options on tu= nnel model also apply to TE topology? TS: I think you are actually asking about somthing that is derrived from routing config, which is also using option #2 (schema mount). LB: Routing config is using it, although the another wildcard form. logical element and network instance in the RTGWG are also using this form. Thi= s would be the 1st use of mounting a specific schema. Loa Anderson: Issues to be fixed on valid ranges of label values. TS: Ack LA: Ambiguous names to be fixed on H-LSP part. LB: What about Extension Labels (RFC7274) TA: will need to consider. DD: Be careful on artifical segmentation around PCC/PCE... DD: The lsp-key is 5 tuple and it should support extensions towards other technologies, e.g., SR. TA: Will have split P2P and P2MP LSPs so will have index within each (sub) trees LA: ietf-te-yang inherits from 2 models; do we need to ensure special revie= w for these cases? 2.3 A YANG Data Model for MPLS Static LSPs https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ Tarek Saad, 20 min (17:10-17:30) Iftekar (Infinera): Who's taking care of switch over? TS: Static configuration. Pre-programmed backups are possible. Behaviors wi= dely depend on DP capabilities. LB: What about OpenConfig's "applied state" discussion? TS: No IETF consensus about its usage so far. LB: Indeed, reco is not to jump to fast, too much error-prone. TS: General consistency matters. LB: From routing area discussion: use to be limited. View as author? Pavan: Agreed on consistency, but eithier way is fine. LB: Simplifying our models might be nice. Maybe we should ask the room. Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback already happened. XL: Not so much work. Structure to be simplified. LA: Would it work if both simplified and more complicated module were pushe= d? LB: Would work, but more implementation load. 2 different ways for every information element; Having just one way to access the information impl= ies less code. LB (chair hat on): How many care? How many for simplified? How many for OpenConfig approach with augmentation? How many for OpenConfig as is? 2.4 TEAS Transport Service Model https://datatracker.ietf.org/doc/draft-zhang-teas-transport-service-model/ Xian Zhang, 15 min (17:30-17:45) Tarek S: I don't understand what's missing from other modules for "step 1". XZ: SB relies on PCEP, this is a service model. Daniele Ceccareli: Is technology-specific only on tunnels or also at servic= e level? XZ: A couple of attributes are relevant for services. DC: OK, so both tunnels and service include technology-specific. Anurag Sharma (Infinera): Commonalty with tunnel: required work? XZ: Many things from tunnels turn optional/unnecessary. Himanshu Shah: Would end up creating something covered by other service mod= els. George Swallow: There seem to be confusion. Service layer may be different = from transport layer (e.g., Ethernet and OTN). Jon: This document is about transport as a service, not end user service HS: Need another document to connect all the dots DC: We can have higher layer services on top of pipe as well as service fil= ling in pipes. We don't have a common service model, like an umbrella. XZ: We are looking at it differently, where we can have the ethernet or OTN service DC: Any plans in mind to solve non-te services? XZ: Plans only for transport/TE. Igor Bryskin: There is no difference between transport or service so lets j= ust use (existing) tunnel model XZ: Indeed, difference is not clear. 2.5 PCEP YANG https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ Dhruv Dhody, 15 min (17:45-18:00) Jeff Tantsura: Key-chain is close to LC. Julien: Who has read document? Who thinks it should be a WG document? Who thinks it shouldn't be a WG document? Clear consensus in the room. Decision will be confirmed by a poll on th= e PCE list. 2.6 YANG Data Model for MPLS LDP and mLDP https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/ Kamran Raza, 15 min (18:00-18:15) No question 2.7 LSP-PING-YANG https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03 Greg Mirsky (remaining time; started at 6:07) Italo Busi: Are you including MEG, MEP, MIP, etc? GM: LSP ping doesn't need those. No intention to introduce them there. Zheng? (Huawei, co-author): Confirmed <6:12 - Meeting adjourned> --_000_BY2PR0201MB1910B13CC46AECC082AF5ACC840E0BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft minutes for the PCE meeting at IETF 96 are= now available.  Thanks to all our minute takers!  Please let me = know if you have any comments or corrections.

https://www.ietf.org/proceedings/96/minutes/minutes-96-p= ce

 

Best regards

Jon

 

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

= PCE Working Group Meeting

= IETF 96 (Berlin)

=  

= Working Group Chairs:

=      Julien Meuric (julien.meuric@orange.com)

=      JP Vasseur (jpv@cisco.com)

=      Jonathan Hardwick (jonathan.hardwick@metaswitch.co= m)

=  

= Working Group Secretary:

=      Daniel King (daniel@olddog.co.uk)

=  

= Responsible AD:

=      Deborah Brungard (db3546@att.com)

=  

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

=  

= ---------------------------------------------------------------------------= ----

= Session I

=  

= Time:

=      July 21, 2016, 14:00-16:00 (2:00pm-4:00pm)

=  

= Location:

=      Tiergarten, Intercontinental Berlin, Germany<= /o:p>

=  

= ---------------------------------------------------------------------------= ----

=  

= 1. Introduction

= ---------------

=  

= 1.1. Administrivia, Agenda Bashing (chairs, 5 min) (14:00-14:05)=

= 1.2. WG Status (chairs, 15 min) (14:05-14:20)

=  

= <draft-ietf-pce-segment-routing>

= Jeff: after fixing the semantics of MSD, we are ready to go

=  

= <pceps>

= Dhruv: The authors dicussed the intended status and felt that due to the

=        implementation maturity and number of = them, we could change from

=        "Experimental" to "Stan= dards Track".

=  

= <stateful-sync>

= Xian: Authors have addressed shepherd review comments.

=  

= <stateful-pce-gmpls>

= <stateful-pce-remote-initiated-gmpls-lsp>

= Xian: Basically ready, but would need WG to provide more feedback.

=  

=  

= 2. Work in Progress

= -------------------

=  

= 2.1 PCEP Hierarchy Extensions

= https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/<= /o:p>

= Dan King, 5 min (14:20-14:25)

=  

= No questions.

=  

= Julien: Regarding moving to standards track, No strong opinion, esp because= of

=         multiple implementation. Will ta= ke it to the list.

=  

=  

= 2.2 Inter-area and Inter-AS Applicability

= https://datatracker.ietf.org/doc/draft-ietf-pce-inter-area-as-applicability= /

= Dan King, 5 min (14:25-14:30)

=  

= No questions.

=  

= Jon: Will move to LC, after the meeting.

=  

=  

= 2.3 PCEP Enhanced Errors

= https://datatracker.ietf.org/doc/draft-ietf-pce-enhanced-errors/=

= Xian Zhang, 10 min (14:30-14:40)

=  

= Dhruv: When this work was presented (IETF 78) some of the procedures and

=        corrosponding errors and notifications= have evolved. The ways in which

=        people are thinking of deploying PCEs = are not necessarily the same.

=        People think more now of deploying hie= rarchical PCE.  I am not sure this

=        document is applicable any more. We wi= ll need to review this document

=        again to ensure it reflects this.=

= Xian: I would like to discuss with Dhruv offline to review these issues.

= Julien: [at mic, chair hat off] yes, ideas have moved on but this does not = make

=         the older ideas invalid.  W= e can update to include newer work.

= Jeff: Yes, it would be good to have some guidelines for the new work, as we=

=       have new mechanisms that need to be reflecte= d

= Jon: Please see the action for someone to contribute text for the Security = and

=      Operational considerations section.

=  

=  

= 2.4 BGP-based PCE Discovery Mechanism

= https://datatracker.ietf.org/doc/draft-dong-pce-discovery-proto-bgp/

= Jie Dong, 10 min (14:40-14:50)

=  

= Poll

= - Who has read this document? [About 12]

= - Who would like to see this become a WG document? [Slightly fewer]

=  

=  

= 3. New Work

= -----------

=  

= 3.1 PCEP Experimental Code Points

= https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/<= /o:p>

= Dhruv Dhody, 10 min (14:50-15:00)

=  

= Adrian: Do this, but. Its not quite right yet. We will need to tweak the

=         proposal. Experiments are good, = and if the ranges are kept small they

=         force developers to an early req= uest for a code point or let go. If a

=         code point is used for an experi= ment and the open source platform then

=         release the version, it might me= an the projct code point squats.

=  

= Dhruv: Could we assign for a specific time period, 1,3,5 years?<= /span>

=  

= Adrian: Sounds like early allocation. I think we need to think about a thir= d

=         way.

=  

= Lou: Respond to Adrian's point, there is a allocation policy, maybe they wa= nt

=      to use a code point for a 1-2 years. Its a "s= pecification required".

=  

= Dhruv: When I read the allocation policy document, it was not clear that wa= s

=        possible.

=  

= Lou: You can also use a "Reserved" method. [See RFC5226?]

=  

= Adrian: This does not exist. It never did.

=  

= Lou: What you're describing is not "experimentation".  Exper= iments are isolated

=      - you should not coordinate code points between ex= periments.  That is an

=      IANA function.  Use IANA if that is what you = want to do.

=  

= Lou: I am also concerned about informal allocation of code points across

=      multiple protocols.

=  

= Dhruv: No, will exclude other/multiple protocols.

=  

= Julien: [Pesonal view] Thats why I like focusing on the essentials.  J= ust the

=         message, object and TLV code poi= nt spaces.

=  

= Jon: I would like to see an experiment registry. Given the IANA sections of= a

=      number of I-Ds I have recently reviewed, I would a= lso like to add

=      experimental ranges for error-types and notficatio= ns.

=  

= Michael: We had a similar problem in TCPM, please look at RFC6994 as it mig= ht

=          address some of the issues= you highlight here.

=  

= Poll

= - Who read the I-D? [A handful]

= - WHo think this is a good base for the discussion? [Similar amount]

=  

=  

= 3.2 Applicability of PCEP to ACTN

= https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/

= Dhruv Dhody, 10 min (15:00-15:10)

=  

= Jon: Yes, it is my fault that you have had to write this I-D. Its helped me= to

=      understand the context of ACTN. The PNC <-> = MSDC is hierachical PCE. The

=      VN Association is not clear as to why the PNCs nee= d to know the VN info,

=      its seems the VN Association info would be used fo= r the MSDC and above.

=      Finally, is PCEP-LS integral to ACTN?

=  

= Dhruv: If you want to use other protocols with ACTN, thats fine. PCEP-LS is= not

=        mandated.

=  

= Jon: Good, so its not fundemental. Is PCECC something that needs to be in t= his

=      applicability document?

=  

= Dhruv: The relationship with PCECC and ACTN is such that PCECC is just one = PNC,

=        and another PNC could be using SR or R= SVP-TE. I will describe the

=        relationship in the document as well.<= o:p>

=  

= Jeff: With PCEP-LS you are creating complexity and capability that already<= o:p>

=       exists with things like BGP-LS.

=  

= Dhruv: It depends how you want to use it, if you use PCECC and you have PCE= P

=        already you can pull TE info via PCEP-= LS and not have to use BGP-LS.

=        There are extremes.<= /p>

=  

= Jeff: You will still be missing link attributes.

=  

= Julien: You should focus on how PCEP-LS may be used for ACTN.

=  

= Pawel Brzozowski: Besides IGPs and BGP-LS we also have YANG.  We also = have Ross

=             &nb= sp;     telling us not to create many ways to do a sing= le thing.  We

=             &nb= sp;     don't need another mechanism.=

=  

=  

= 3.3 Hierarchical PCE Discovery

= https://datatracker.ietf.org/doc/draft-chen-pce-h-discovery/

= Huaimo Chen, 10 min (15:10-15:20)

=  

= Julien: Does the Parent PCE really need to discover further information abo= ut

=         the Child PCE, if I have already= manually configured this info

=         (capability and reachability).

= Huaimo: We need to confirm the configration in the protocol.

= Julien: It is not discovery, it is a configuration check.  Is this inf= ormation

=         dynamic?

= Huaimo: There are security consideration, which is why configuration must b= e

=         validated.

=  

=  

= 3.4 Connections and Accesses for Hierarchical PCE

= https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/

= Huaimo Chen, 10 min (15:20-15:30)

=  

= Adrian: Your identified requirements mentioned H-PCE architecture (RFC6805)= ,

=         but I think there are methods av= ailable for discovery and dissemination

=         of inter-domain links. These req= uirements might be solved by things

=         like BGP-LS. Depending the deplo= yment and configuration policy, you may

=         find the operator will already k= now which links exist between domains.

= Huaimo: Some times they dont, here we provide a easy way to provide that

=         information.

= Igor: What if there is no link between domains, how does the parent PCE com= pute

=       a inter-domain path?

= Huaimo: Bad luck.

= Igor: If I report (parent PCE) I cannot compute a path, how do I handle thi= s?

= Anton Ivamnov: We have BGP-LS, this should be closed.

= Julien: The usecase is the same, you are duplicating the work already done.=

=  

=  

= 3.5 Native PCE TED

= https://datatracker.ietf.org/doc/draft-chen-pce-pcc-ted/<= /p>

= Huaimo Chen, 10 min (15:30-15:40)

=  

= Adrian: The first slide is misleading, what you have is a partial diagram f= rom

=         RFC 4655.  You want to exte= nd this to a node not running a routing

=         protocol and using PCEP to learn= TED.

= Huaimo: Yes.

=  

=  

= ---------------------------------------------------------------------------= ----

= Session II

= Joint YANG session with MPLS & TEAS & PCE

=  

= Time:

=      July 21, 2016, 16:20-18:20 (4:20pm-6:20pm)

=  

= Location:

=      Charlottenburg II/III, Intercontinental Berlin, Ge= rmany

=  

= ---------------------------------------------------------------------------= ----

=  

= Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pa= van

= and Jon taken by Lou and George.

=  

= 1. Introduction

= ---------------

=  

= 1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30)<= o:p>

=  

=  

= 2. YANG models discussion

= -------------------------

=  

= 2.1 YANG Data Model for TE Topologies

= https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/

= Xufeng Liu, 20 min (16:30-16:50)

=  

= Dhruv Dhody: Relationship with SR model?

= XL: Types to be shared.

= DD: Do we need RW on per-node attributes?

= Tarek: There are cases where information is learned via IGP, but other case= s

=        where static may be supported, thus th= e need for RW

= DD: What do we do on conflicts? TBD

= Igor Bryskin: one of the clients (users?) wanted to do path computation bas= ed

=             &nb= sp; on TE information as well

= Pavan: How many have read? Not so many. Please read and send comments to th= e

=        list.

=  

=  

= 2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces

= https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/=

= Tarek Saad, 20 min (16:50-17:10)

=  

= Lou Berger: Send that [option request] to Netmod.

= Xian Zhang: No strong preference among options, but, do these options on tu= nnel

=             model al= so apply to TE topology?

= TS: I think you are actually asking about somthing that is derrived from

=     routing config, which is also using  option #2 (sch= ema mount).

= LB: Routing config is using it, although the another wildcard form. logical=

=     element and network instance in the RTGWG are also using= this form. This

=     would be the 1st use of mounting a specific schema.=

= Loa Anderson: Issues to be fixed on valid ranges of label values.

= TS: Ack

= LA: Ambiguous names to be fixed on H-LSP part.

= LB: What about Extension Labels (RFC7274)

= TA: will need to consider.

= DD: Be careful on artifical segmentation around PCC/PCE...

= DD: The lsp-key is 5 tuple and it should support extensions towards other

=     technologies, e.g., SR.

= TA: Will have split P2P and P2MP LSPs so will have index within each (sub)<= o:p>

=     trees

= LA: ietf-te-yang inherits from 2 models; do we need to ensure special revie= w

=     for these cases?

=  

=  

= 2.3 A YANG Data Model for MPLS Static LSPs

= https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/

= Tarek Saad, 20 min (17:10-17:30)

=  

= Iftekar (Infinera): Who's taking care of switch over?

= TS: Static configuration. Pre-programmed backups are possible. Behaviors wi= dely

=     depend on DP capabilities.

= LB: What about OpenConfig's "applied state" discussion?

= TS: No IETF consensus about its usage so far.

= LB: Indeed, reco is not to jump to fast, too much error-prone.

= TS: General consistency matters.

= LB: From routing area discussion: use to be limited. View as author?

= Pavan: Agreed on consistency, but eithier way is fine.

= LB: Simplifying our models might be nice. Maybe we should ask the room.

= Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback=

=             &nb= sp;        already happened.<= /span>

= XL: Not so much work. Structure to be simplified.

= LA: Would it work if both simplified and more complicated module were pushe= d?

= LB: Would work, but more implementation load.  2 different ways for ev= ery

=     information element; Having just one way to access the i= nformation implies

=     less code.

= LB (chair hat on):

=     How many care? <A decent number, but "not as man= y as expected">

=     How many for simplified? <Almost the same>

=     How many for OpenConfig approach with augmentation? <= A small number>

=     How many for OpenConfig as is? <One>

=  

=  

= 2.4 TEAS Transport Service Model

= https://datatracker.ietf.org/doc/draft-zhang-teas-transport-service-model/<= o:p>

= Xian Zhang, 15 min (17:30-17:45)

=  

= Tarek S: I don't understand what's missing from other modules for "ste= p 1".

= XZ: SB relies on PCEP, this is a service model.

= Daniele Ceccareli: Is technology-specific only on tunnels or also at servic= e

=             &nb= sp;      level?

= XZ: A couple of attributes are relevant for services.

= DC: OK, so both tunnels and service include technology-specific.=

= Anurag Sharma (Infinera): Commonalty with tunnel: required work?=

= XZ: Many things from tunnels turn optional/unnecessary.

= Himanshu Shah: Would end up creating something covered by other service mod= els.

= George Swallow: There seem to be confusion. Service layer may be different = from

=             &nb= sp;   transport layer (e.g., Ethernet and OTN).=

= Jon: This document is about transport as a service, not end user service

= HS: Need another document to connect all the dots

= DC: We can have higher layer services on top of pipe as well as service fil= ling

=     in pipes. We don't have a common service model, like an = umbrella.

= XZ: We are looking at it differently, where we can have the ethernet or OTN=

=     service

= DC: Any plans in mind to solve non-te services?

= XZ: Plans only for transport/TE.

= Igor Bryskin: There is no difference between transport or service so lets j= ust

=             &nb= sp; use (existing) tunnel model

= XZ: Indeed, difference is not clear.

=  

=  

= 2.5 PCEP YANG

= https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/=

= Dhruv Dhody, 15 min (17:45-18:00)

=  

= Jeff Tantsura: Key-chain is close to LC.

=  

= Julien: Who has read document? <Some>

=  

=     Who thinks it should be a WG document? <more!>

=  

=     Who thinks it shouldn't be a WG document? <none>

=  

=     Clear consensus in the room. Decision will be confirmed = by a poll on the

=     PCE list.

=  

=  

= 2.6 YANG Data Model for MPLS LDP and mLDP

= https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/<= /span>

= Kamran Raza, 15 min (18:00-18:15)

=  

= No question

=  

=  

= 2.7 LSP-PING-YANG

= https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03

= Greg Mirsky (remaining time; started at 6:07)

=  

= Italo Busi: Are you including MEG, MEP, MIP, etc?

= GM: LSP ping doesn't need those. No intention to introduce them there.=

= Zheng? (Huawei, co-author): Confirmed

=  

= <6:12 - Meeting adjourned>

 

=  

--_000_BY2PR0201MB1910B13CC46AECC082AF5ACC840E0BY2PR0201MB1910_-- From nobody Tue Jul 26 06:31:29 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4F312DAB4; Tue, 26 Jul 2016 06:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMGPcKJEkHCS; Tue, 26 Jul 2016 06:31:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4600412DC7D; Tue, 26 Jul 2016 06:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jFYyhf3oaw65U0f8YqTNmnj2ABeQpoU5/dMoKy5flPg=; b=rDBGVxw4KmDlRpZvtJ1D1hoJLL0jsj/wIs2MiH6YmhqsM05s1ytJJzui6umvZJE1CJvOXikfxTBFvgKiM36Nw19CfMWns4zTC/JVKmCTE6Ilb552IydlSvX7ChNCOxk38RNr3rwuLsH9TqqNryye1grJDkipQ1WI/Z0NDnrEiDA= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 26 Jul 2016 13:14:47 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Tue, 26 Jul 2016 13:14:47 +0000 From: Jonathan Hardwick To: "mpls@ietf.org" , "pce@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: MPLS/PCE/TEAS YANG meeting minutes available Thread-Index: AdHnP0O3t+zic4iEQxet5W8fSbNGgg== Date: Tue, 26 Jul 2016 13:14:47 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.85.254] x-ms-office365-filtering-correlation-id: d9cca83d-dbfa-48f7-ee10-08d3b556d170 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 6:i9tNxUn+DGw8Lsj+y5rXGt2aqMr/FJ17Sm3TmIUoI+CbsnmSmim3JdE0b5i+aV6OGYvEyfZL4og7j+Xmpm6cy7DzU8vm+sbogiK6DUiQBJs3uq+fUiHMD1ycTpnWCwwgbRvufrmFl22CJu2RZ25SylZfIsSxLwaD8l9ZoKewTjAgHitzrsLP5hAyoG1R5/FEF8Dl6y+CPhhioxBkRtgsn6eDDVYLQ7dsYn6I+DPm7D7RWxZjHyj+lMagx+6NA/AGW5vULtd95kxhS7mOXAcHaDle2Ce2Y91b1fBhO2T/BsE=; 5:y3oxnP09KkMyx++9rdS/N/XIORo5k3k4qWftN1LpQh88blnhLzQdOdTwJy8+g/vmMRF8uwJEgAMWCnWx2RedFdnx7KHZRs4+B3aYhjkBqDsu9sxaVrSA/Kzg+0EHKXD6Q+26LCfKT9NFExiNFZUXDA==; 24:52EnjYhBmL/PeYSFMrdha4w3Ubsn8LHElGcFedT0/AM6NK3L3+UDtThzDWlm/jps/24hyozvKwtMpHL6aiKxdzBElIPgxKzzlFO0bJHj6j0=; 7:7EGh14/XHRKS61/hLeCWd7jl0BHQmTEUaS3PIzFkeH6kvqbPtid7130Eus0ZTBLeTRK+Sbv/CqNxQ1lrblAasJ7ponT81j6IMbdk7Rw+P+mNKB/pWSUZl3I/z+LrKLaawaflI4sQ1AzajetWSe51FoHW+e/xyANkajmD7wg2UJJetwIWgqzzJUUNQH3OyJKdT7GDixlKBJSyJpUdffSScCw0UxN6wzL/ZABKzZZ9OWZkb9PWzuGo7fEZBk36QE1/ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1909; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(54164003)(189002)(57704003)(199003)(77096005)(5003600100003)(7906003)(74316002)(2900100001)(16236675004)(19617315012)(105586002)(15975445007)(86362001)(5002640100001)(3846002)(97736004)(66066001)(106356001)(122556002)(101416001)(99286002)(76576001)(4326007)(7696003)(5001770100001)(92566002)(7736002)(87936001)(81166006)(790700001)(7846002)(2501003)(81156014)(102836003)(6116002)(19300405004)(10400500002)(3280700002)(8676002)(586003)(9686002)(19580395003)(68736007)(19625215002)(2906002)(54356999)(3660700001)(11100500001)(229853001)(8936002)(450100001)(33656002)(189998001)(50986999)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910DD268B9AFE84EDDC2A38840E0BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 13:14:47.2623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909 Archived-At: Cc: "teas-chairs@ietf.org" , "mpls-chairs@ietf.org" , "pce-chairs@ietf.org" Subject: [Pce] MPLS/PCE/TEAS YANG meeting minutes available X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:31:10 -0000 --_000_BY2PR0201MB1910DD268B9AFE84EDDC2A38840E0BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft minutes for the joint MPLS/PCE/TEAS YANG meeting at IETF 96 are n= ow available. Please see "session II" at the link below. Thanks to all ou= r minute takers! Please let me know if you have any comments or correction= s. https://www.ietf.org/proceedings/96/minutes/minutes-96-pce Best regards Jon ---------------------------------------------------------------------------= ---- Session II Joint YANG session with MPLS & TEAS & PCE Time: July 21, 2016, 16:20-18:20 (4:20pm-6:20pm) Location: Charlottenburg II/III, Intercontinental Berlin, Germany ---------------------------------------------------------------------------= ---- Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pa= van and Jon taken by Lou and George. 1. Introduction --------------- 1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30) 2. YANG models discussion ------------------------- 2.1 YANG Data Model for TE Topologies https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ Xufeng Liu, 20 min (16:30-16:50) Dhruv Dhody: Relationship with SR model? XL: Types to be shared. DD: Do we need RW on per-node attributes? Tarek: There are cases where information is learned via IGP, but other case= s where static may be supported, thus the need for RW DD: What do we do on conflicts? TBD Igor Bryskin: one of the clients (users?) wanted to do path computation bas= ed on TE information as well Pavan: How many have read? Not so many. Please read and send comments to th= e list. 2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ Tarek Saad, 20 min (16:50-17:10) Lou Berger: Send that [option request] to Netmod. Xian Zhang: No strong preference among options, but, do these options on tu= nnel model also apply to TE topology? TS: I think you are actually asking about somthing that is derrived from routing config, which is also using option #2 (schema mount). LB: Routing config is using it, although the another wildcard form. logical element and network instance in the RTGWG are also using this form. Thi= s would be the 1st use of mounting a specific schema. Loa Anderson: Issues to be fixed on valid ranges of label values. TS: Ack LA: Ambiguous names to be fixed on H-LSP part. LB: What about Extension Labels (RFC7274) TA: will need to consider. DD: Be careful on artifical segmentation around PCC/PCE... DD: The lsp-key is 5 tuple and it should support extensions towards other technologies, e.g., SR. TA: Will have split P2P and P2MP LSPs so will have index within each (sub) trees LA: ietf-te-yang inherits from 2 models; do we need to ensure special revie= w for these cases? 2.3 A YANG Data Model for MPLS Static LSPs https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/ Tarek Saad, 20 min (17:10-17:30) Iftekar (Infinera): Who's taking care of switch over? TS: Static configuration. Pre-programmed backups are possible. Behaviors wi= dely depend on DP capabilities. LB: What about OpenConfig's "applied state" discussion? TS: No IETF consensus about its usage so far. LB: Indeed, reco is not to jump to fast, too much error-prone. TS: General consistency matters. LB: From routing area discussion: use to be limited. View as author? Pavan: Agreed on consistency, but eithier way is fine. LB: Simplifying our models might be nice. Maybe we should ask the room. Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback already happened. XL: Not so much work. Structure to be simplified. LA: Would it work if both simplified and more complicated module were pushe= d? LB: Would work, but more implementation load. 2 different ways for every information element; Having just one way to access the information impl= ies less code. LB (chair hat on): How many care? How many for simplified? How many for OpenConfig approach with augmentation? How many for OpenConfig as is? 2.4 TEAS Transport Service Model https://datatracker.ietf.org/doc/draft-zhang-teas-transport-service-model/ Xian Zhang, 15 min (17:30-17:45) Tarek S: I don't understand what's missing from other modules for "step 1". XZ: SB relies on PCEP, this is a service model. Daniele Ceccareli: Is technology-specific only on tunnels or also at servic= e level? XZ: A couple of attributes are relevant for services. DC: OK, so both tunnels and service include technology-specific. Anurag Sharma (Infinera): Commonalty with tunnel: required work? XZ: Many things from tunnels turn optional/unnecessary. Himanshu Shah: Would end up creating something covered by other service mod= els. George Swallow: There seem to be confusion. Service layer may be different = from transport layer (e.g., Ethernet and OTN). Jon: This document is about transport as a service, not end user service HS: Need another document to connect all the dots DC: We can have higher layer services on top of pipe as well as service fil= ling in pipes. We don't have a common service model, like an umbrella. XZ: We are looking at it differently, where we can have the ethernet or OTN service DC: Any plans in mind to solve non-te services? XZ: Plans only for transport/TE. Igor Bryskin: There is no difference between transport or service so lets j= ust use (existing) tunnel model XZ: Indeed, difference is not clear. 2.5 PCEP YANG https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/ Dhruv Dhody, 15 min (17:45-18:00) Jeff Tantsura: Key-chain is close to LC. Julien: Who has read document? Who thinks it should be a WG document? Who thinks it shouldn't be a WG document? Clear consensus in the room. Decision will be confirmed by a poll on th= e PCE list. 2.6 YANG Data Model for MPLS LDP and mLDP https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/ Kamran Raza, 15 min (18:00-18:15) No question 2.7 LSP-PING-YANG https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03 Greg Mirsky (remaining time; started at 6:07) Italo Busi: Are you including MEG, MEP, MIP, etc? GM: LSP ping doesn't need those. No intention to introduce them there. Zheng? (Huawei, co-author): Confirmed <6:12 - Meeting adjourned> --_000_BY2PR0201MB1910DD268B9AFE84EDDC2A38840E0BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft minutes for the joint MPLS/PCE/TEAS YANG m= eeting at IETF 96 are now available.  Please see “session IIR= 21; at the link below.  Thanks to all our minute takers!  Please = let me know if you have any comments or corrections.

https://www.ietf.org/proceedings/96/minutes/minutes-96-p= ce

 

Best regards

Jon

 

= ---------------------------------------------------------------------------= ----

= Session II

= Joint YANG session with MPLS & TEAS & PCE

=  

= Time:

=      July 21, 2016, 16:20-18:20 (4:20pm-6:20pm)

=  

= Location:

=      Charlottenburg II/III, Intercontinental Berlin, Ge= rmany

=  

= ---------------------------------------------------------------------------= ----

=  

= Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pa= van

= and Jon taken by Lou and George.

=  

= 1. Introduction

= ---------------

=  

= 1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30)<= o:p>

=  

=  

= 2. YANG models discussion

= -------------------------

=  

= 2.1 YANG Data Model for TE Topologies

= = https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/

= Xufeng Liu, 20 min (16:30-16:50)

=  

= Dhruv Dhody: Relationship with SR model?

= XL: Types to be shared.

= DD: Do we need RW on per-node attributes?

= Tarek: There are cases where information is learned via IGP, but other case= s

=        where static may be supported, thus th= e need for RW

= DD: What do we do on conflicts? TBD

= Igor Bryskin: one of the clients (users?) wanted to do path computation bas= ed

=             &nb= sp; on TE information as well

= Pavan: How many have read? Not so many. Please read and send comments to th= e

=        list.

=  

=  

= 2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces

= https= ://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/<= /p>

= Tarek Saad, 20 min (16:50-17:10)

=  

= Lou Berger: Send that [option request] to Netmod.

= Xian Zhang: No strong preference among options, but, do these options on tu= nnel

=             model al= so apply to TE topology?

= TS: I think you are actually asking about somthing that is derrived from

=     routing config, which is also using  option #2 (sch= ema mount).

= LB: Routing config is using it, although the another wildcard form. logical=

=     element and network instance in the RTGWG are also using= this form. This

=     would be the 1st use of mounting a specific schema.=

= Loa Anderson: Issues to be fixed on valid ranges of label values.

= TS: Ack

= LA: Ambiguous names to be fixed on H-LSP part.

= LB: What about Extension Labels (RFC7274)

= TA: will need to consider.

= DD: Be careful on artifical segmentation around PCC/PCE...

= DD: The lsp-key is 5 tuple and it should support extensions towards other

=     technologies, e.g., SR.

= TA: Will have split P2P and P2MP LSPs so will have index within each (sub)<= o:p>

=     trees

= LA: ietf-te-yang inherits from 2 models; do we need to ensure special revie= w

=     for these cases?

=  

=  

= 2.3 A YANG Data Model for MPLS Static LSPs

= h= ttps://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/=

= Tarek Saad, 20 min (17:10-17:30)

=  

= Iftekar (Infinera): Who's taking care of switch over?

= TS: Static configuration. Pre-programmed backups are possible. Behaviors wi= dely

=     depend on DP capabilities.

= LB: What about OpenConfig's "applied state" discussion?

= TS: No IETF consensus about its usage so far.

= LB: Indeed, reco is not to jump to fast, too much error-prone.

= TS: General consistency matters.

= LB: From routing area discussion: use to be limited. View as author?

= Pavan: Agreed on consistency, but eithier way is fine.

= LB: Simplifying our models might be nice. Maybe we should ask the room.

= Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback=

=             &nb= sp;        already happened.<= /span>

= XL: Not so much work. Structure to be simplified.

= LA: Would it work if both simplified and more complicated module were pushe= d?

= LB: Would work, but more implementation load.  2 different ways for ev= ery

=     information element; Having just one way to access the i= nformation implies

=     less code.

= LB (chair hat on):

=     How many care? <A decent number, but "not as man= y as expected">

=     How many for simplified? <Almost the same>

=     How many for OpenConfig approach with augmentation? <= A small number>

=     How many for OpenConfig as is? <One>

=  

=  

= 2.4 TEAS Transport Service Model

= https://datatracker.ietf.org/doc/draft-zhang-teas-transport-ser= vice-model/

= Xian Zhang, 15 min (17:30-17:45)

=  

= Tarek S: I don't understand what's missing from other modules for "ste= p 1".

= XZ: SB relies on PCEP, this is a service model.

= Daniele Ceccareli: Is technology-specific only on tunnels or also at servic= e

=             &nb= sp;      level?

= XZ: A couple of attributes are relevant for services.

= DC: OK, so both tunnels and service include technology-specific.=

= Anurag Sharma (Infinera): Commonalty with tunnel: required work?=

= XZ: Many things from tunnels turn optional/unnecessary.

= Himanshu Shah: Would end up creating something covered by other service mod= els.

= George Swallow: There seem to be confusion. Service layer may be different = from

=             &nb= sp;   transport layer (e.g., Ethernet and OTN).=

= Jon: This document is about transport as a service, not end user service

= HS: Need another document to connect all the dots

= DC: We can have higher layer services on top of pipe as well as service fil= ling

=     in pipes. We don't have a common service model, like an = umbrella.

= XZ: We are looking at it differently, where we can have the ethernet or OTN=

=     service

= DC: Any plans in mind to solve non-te services?

= XZ: Plans only for transport/TE.

= Igor Bryskin: There is no difference between transport or service so lets j= ust

=             &nb= sp; use (existing) tunnel model

= XZ: Indeed, difference is not clear.

=  

=  

= 2.5 PCEP YANG

= https= ://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/<= /p>

= Dhruv Dhody, 15 min (17:45-18:00)

=  

= Jeff Tantsura: Key-chain is close to LC.

=  

= Julien: Who has read document? <Some>

=  

=     Who thinks it should be a WG document? <more!>

=  

=     Who thinks it shouldn't be a WG document? <none>

=  

=     Clear consensus in the room. Decision will be confirmed = by a poll on the

=     PCE list.

=  

=  

= 2.6 YANG Data Model for MPLS LDP and mLDP

= https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/

= Kamran Raza, 15 min (18:00-18:15)

=  

= No question

=  

=  

= 2.7 LSP-PING-YANG

= https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03

= Greg Mirsky (remaining time; started at 6:07)

=  

= Italo Busi: Are you including MEG, MEP, MIP, etc?

= GM: LSP ping doesn't need those. No intention to introduce them there.=

= Zheng? (Huawei, co-author): Confirmed

=  

= <6:12 - Meeting adjourned>

=  

=  

 

 

--_000_BY2PR0201MB1910DD268B9AFE84EDDC2A38840E0BY2PR0201MB1910_-- From nobody Tue Jul 26 06:59:13 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C5B12DBBE; Tue, 26 Jul 2016 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYFdTdRiH9IN; Tue, 26 Jul 2016 06:59:09 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0129.outbound.protection.outlook.com [104.47.34.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DD012DC03; Tue, 26 Jul 2016 06:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7XjsjvZyIF0+Gy2z2quc96OfuQdvgzUeL00ytpe39dc=; b=F2cAV4bwIvAXBuT475jAm6zMc1zd2HDJh58OkuFG+lMs4j0R96BIctGIUOvejvVfSbptXTyPme2eLEaWKsldIZJu4r1BAV2O42cruaLZeu7vHblY/bLc4/tG/jZyYkMeiwfyrBwNwqaL0jZnFSTFf2MuzvvZCNQGXCystQTFFiY= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1912.namprd02.prod.outlook.com (10.163.75.154) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 26 Jul 2016 13:48:17 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Tue, 26 Jul 2016 13:48:17 +0000 From: Jonathan Hardwick To: "pce@ietf.org" Thread-Topic: Moving draft-ietf-pce-hierarchy-extensions onto the standards track Thread-Index: AdHnQ4q21Z7q0ls3S82oon24KDUtSA== Date: Tue, 26 Jul 2016 13:48:17 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.85.254] x-ms-office365-filtering-correlation-id: 801d6dcd-732c-41d0-7003-08d3b55b7f83 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1912; 6:PguFQfFdJ6XJLjvijVmqoqWqqeHudPMzeBteY9Yetc/fALaZzZgTcCHHat4DRRWwBgqnpCTZYcTUEhSBnfIoXZWoqWqol8Tb7yA8qZImY235UiSqIN4rh73wh6lwrMq3HozN01Sx3iEyfyjAzNfgslphe/nuGT+RWgMA0Z0tWU0dXJ09rrOfChT+yBLYeQD/a6Z+p/DyppKEB1Hl2h5yS9qW5RSSJutmRPtn6jJrUJuz6+8jZ6VPV9KI8SfIw6dZkL9cVu8T594oF3FRyqaZraMqbFoCuF5jN37KAj1zgSmKJIde6tS2NrHitLSyt7Du; 5:BTOiu86yk1iNXpquGd3euQDUsqkUiIBkuMn7h9uN6cw2/xcB9aCXJ63/CSX/KZB51EOOpFUKD/j+E3JjS6OUiGWtnlxEoz6HTcpdOhf/8BkqCflkdXPRkUUTbWOH/f0vKfe8cyADpe+3b/IbHyifCQ==; 24:XTQhDQFym1aPdJPekxTkkTJa9DwkYmg9H62j/WIzbfvtmol7VtHhWCILrYZvQiiPc1hf2wUyhhXP61A6oM0qZYpj8jbzqsUvpC50i9CV8/o=; 7:duOm7ejSYMWk0EoLmOKLswnAUk0yIc4x9UucXyxsBnYSazMmON3SmMI66i3A2igVWyP1bRpRNRar9VA3AgBxl+cFBoO+g3KUHOfLKLyex5602KqzyxiskhitmXntNBMh6o07hGkpmZq9KAoi/teRFU2xpfTlT3sSh+ICgoU3VCtE5XHWD5AzVL4a14meGGIAdXxDaVArbVvmreoNqtuOYJEbFEhSvKhzE24zwcxdJSIusRIzCQIjLViFFeZKUQ7+I0C3Yjoe5GwlOWs5cJ1hbQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1912; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1912; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(66654002)(199003)(189002)(7906003)(230783001)(74316002)(97736004)(19580395003)(8936002)(3660700001)(1730700003)(81166006)(19625215002)(101416001)(8676002)(81156014)(4326007)(87936001)(5002640100001)(5630700001)(66066001)(2906002)(229853001)(2501003)(105586002)(106356001)(2351001)(189998001)(5640700001)(19300405004)(19617315012)(3280700002)(110136002)(33656002)(99286002)(76576001)(122556002)(92566002)(10400500002)(9686002)(6116002)(15975445007)(5003600100003)(7696003)(586003)(86362001)(7736002)(11100500001)(16236675004)(77096005)(102836003)(790700001)(3846002)(450100001)(2900100001)(50986999)(7846002)(68736007)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1912; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910BF6D0510D4F6B9CB3A8E840E0BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 13:48:17.2991 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1912 Archived-At: Cc: "pce-chairs@ietf.org" Subject: [Pce] Moving draft-ietf-pce-hierarchy-extensions onto the standards track X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 13:59:11 -0000 --_000_BY2PR0201MB1910BF6D0510D4F6B9CB3A8E840E0BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear PCE WG At the recent IETF meeting, the authors of the above document requested tha= t the document be moved from Experimental status onto the standards track. = This is in consequence of there now being multiple implementations of the = H-PCE protocol extensions, and H-PCE becoming important for new application= s like ACTN. Please see the meeting slides for details. https://www.ietf.org/proceedings/96/slides/slides-96-pce-15.pdf https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/ Please send an email to the list if you have any comments or objections to = doing this, by Friday 12 August. If you do not reply, we will treat it as = "no objection". Many thanks Jon, JP and Julien --_000_BY2PR0201MB1910BF6D0510D4F6B9CB3A8E840E0BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear PCE WG

 

At the recent IETF meeting, the authors of the above= document requested that the document be moved from Experimental status ont= o the standards track.  This is in consequence of there now being mult= iple implementations of the H-PCE protocol extensions, and H-PCE becoming important for new applications like ACTN.&n= bsp; Please see the meeting slides for details.

https://www.ietf.org/proceedings/96/slides/slides-9= 6-pce-15.pdf

https://datatracker.ietf.org/doc/draft-ietf-p= ce-hierarchy-extensions/

 

Please send an email to the list if you have any com= ments or objections to doing this, by Friday 12 August.  If you do not= reply, we will treat it as “no objection”.

 

Many thanks

Jon, JP and Julien

 

--_000_BY2PR0201MB1910BF6D0510D4F6B9CB3A8E840E0BY2PR0201MB1910_-- From nobody Tue Jul 26 08:27:22 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC7E12DDD7; Tue, 26 Jul 2016 08:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZleGdOv2i9G; Tue, 26 Jul 2016 08:27:11 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0098.outbound.protection.outlook.com [104.47.37.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BCC12DDDB; Tue, 26 Jul 2016 07:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u77yeVsnA1MpX6buvWrxwCCCtFd0d48kY6KXFvE2oGs=; b=NSMPCn5YWcHuBUZfCNtnYtrEwdXPp3FzGRJQxul9gpBefEkVa6xg6PLAOoy0NMzPrAJlF8IwNz8OUV8lV8/hssixnQPx44NCgHcsPuBjmEMRveRcWz84WkCmvwNwLeET6WIzxNOBDWuvbM/PkdnGot0E/W7n1Z45f9OcpygMQao= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 26 Jul 2016 14:53:16 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0528.017; Tue, 26 Jul 2016 14:53:16 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-stateful-pce-app@ietf.org" Thread-Topic: Progressing draft-ietf-pce-stateful-pce-app-06 Thread-Index: AdHnTTKPS5BawiaSRTOBBH68AwtOVA== Date: Tue, 26 Jul 2016 14:53:15 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [81.132.85.254] x-ms-office365-filtering-correlation-id: 3747afd9-7ddc-47f6-5b15-08d3b5649334 x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 6:weI2KHQA/ISrYsfbon+/xBsh5Xbz7ezRQznRJgfM8Y+T016qtLxHM9nhGX8T3h1g0AB6XPeJH0N0EofcjhMSX6CZudK2HG7y7pogA/WdMYC/QIzg4drNVOR4gdHjpuZtgZu1cBCxzU97V9w1LZPn1Dhb3+yUfUaTgyDNQ2wUt/HeD91uwReNxscu0flwIw4W74C9X1/JRbapbHCbVmnjCaR4Y8Yxl713HlF4BulcbDr22wp2VTBHrVv97LxngP6/Wps6mLufieo2LB9Fjf3+1wpCc6jpVKLu2tffuRN3+5Q=; 5:UtUhgCLeKHnM/Melxlq4j8qWyy/1Ax3g1GeUp79LVXq1cUPpRtxOAgbRUm+jpBy5FEsm/55jaw4Il4149F6/IVLUOujqDCELaaQN9depaEOdplNUhPhCal1XZfKPkbf7nlPEHc8a5CLSJMY0m+rUpQ==; 24:67Z7q6PTNQ6wvnl2Mk16n8TTlEnM68bwb/v0dDYuPQM2vLBYNgwiIeKN/AQf6fB9QfYtVATrkvJxEWJ1aWPVh0gOTWO4WQvgajzuAHnW9eM=; 7:7/4hxGJgXe33TYBmzVV9tZosMs3NwtMPbSP/OUpEj96C0ytbR76USxi/RzgXFnFKofP8oF8vC64W5bIiVk7dj1PjzaP0YqqIOghf0e8efgC6QFJVO+Zc7iQJfmJdvWpE0Ezm9W10YbqZGmbWesBJlEabnGuY5r7HD2cbaxfaNSQF+oX09RB/rMjEnSzRNAsrKhdzhEjCs6lMCWjgqgr7kYu+biK8yDHKQQ7VSSjgodw63xuk8L0iBJwq9h56Ij9W x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1909; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(69234005)(199003)(19580395003)(2351001)(8676002)(9686002)(586003)(19300405004)(10400500002)(3280700002)(50986999)(33656002)(189998001)(19625215002)(68736007)(2906002)(54356999)(11100500001)(229853001)(8936002)(450100001)(3660700001)(110136002)(86362001)(5002640100001)(66066001)(101416001)(122556002)(106356001)(3846002)(5640700001)(97736004)(2900100001)(230783001)(5003600100003)(77096005)(105586002)(15975445007)(16236675004)(74316002)(7846002)(2501003)(81156014)(5630700001)(81166006)(87936001)(790700001)(6116002)(102836003)(76576001)(99286002)(4326007)(92566002)(7736002)(7696003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB1910FB93C65CACB34A8B4061840E0BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 14:53:15.7828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909 Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Progressing draft-ietf-pce-stateful-pce-app-06 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 15:27:19 -0000 --_000_BY2PR0201MB1910FB93C65CACB34A8B4061840E0BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted this draft to the IESG for publication. A copy of my shep= herd write-up is below FYI. Best regards Jon (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational - indicated in the title page header. This is the correct type as the draft is an applicability statement. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations. Working Group Summary This document contains text that was originally included in the base stateful PCE protocol specification. The WG decided to split the text into a separate applicability statement to allow additional use cases to be contributed and the whole document edited in parallel. Use cases were contributed by several WG members for a variety of MPLS and GMPLS applications. There has been no particular controversy and the consensus behind the document is good. Document Quality The text has been worked on over a long period and has been scrutinized by several reviewers. There are several stateful PCE implementations covering the full range of scenarios presented by this applicability statement. Personnel Jonathan Hardwick is the Document Shepherd. Deborah Brungard is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I reviewed this text carefully twice, once when it was under initial development as part of the stateful PCE protocol specification, and again when preparing to submit the document for IESG review. In my opinion the document is ready to be published. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Good consensus across the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Just a couple of outdated references to other drafts. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document does not specify any actions for IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A. --_000_BY2PR0201MB1910FB93C65CACB34A8B4061840E0BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have submitted this draft to the IESG for publicat= ion.  A copy of my shepherd write-up is below FYI.

Best regards

Jon

 

(1) What type of RFC is being requested (BCP, Proposed Standard,=

Internet Standard, Informational, Experimental, or Historic)?  W= hy

is this the proper type of RFC?  Is this type of RFC indicated i= n the

title page header?

 

  Informational - indicated in the title page header.=

  This is the correct type as the draft is an applicability stat= ement.

 

 

(2) The IESG approval announcement includes a Document Announcement

Write-Up. Please provide such a Document Announcement Write-Up. Recen= t

examples can be found in the "Action" announcements for app= roved

documents. The approval announcement contains the following sections:=

 

Technical Summary

 

  A stateful Path Computation Element (PCE) maintains informatio= n about

  Label Switched Path (LSP) characteristics and resource usage w= ithin a

  network in order to provide traffic engineering calculations f= or its

  associated Path Computation Clients (PCCs).  This documen= t describes

  general considerations for a stateful PCE deployment and exami= nes its

  applicability and benefits, as well as its challenges and limi= tations.

 

Working Group Summary

 

  This document contains text that was originally included in th= e base

  stateful PCE protocol specification.  The WG decided to s= plit the

  text into a separate applicability statement to allow addition= al

  use cases to be contributed and the whole document edited in p= arallel.

  Use cases were contributed by several WG members for a variety= of MPLS

  and GMPLS applications.  There has been no particular con= troversy and

  the consensus behind the document is good.

 

Document Quality

 

  The text has been worked on over a long period and has been sc= rutinized

  by several reviewers.  There are several stateful PCE imp= lementations

  covering the full range of scenarios presented by this applica= bility

  statement.

 

Personnel

 

  Jonathan Hardwick is the Document Shepherd.  Deborah Brun= gard is the

  Responsible Area Director.

 

 

(3) Briefly describe the review of this document that was performed b= y

the Document Shepherd.  If this version of the document is not r= eady

for publication, please explain why the document is being forwarded t= o

the IESG.

 

  I reviewed this text carefully twice, once when it was under i= nitial

  development as part of the stateful PCE protocol specification= , and

  again when preparing to submit the document for IESG review.&n= bsp; In my

  opinion the document is ready to be published.

 

 

(4) Does the document Shepherd have any concerns about the depth or

breadth of the reviews that have been performed?

 

  No.

 

 

(5) Do portions of the document need review from a particular or from=

broader perspective, e.g., security, operational complexity, AAA, DNS= ,

DHCP, XML, or internationalization? If so, describe the review that

took place.

 

  No.

 

 

(6) Describe any specific concerns or issues that the Document Shephe= rd

has with this document that the Responsible Area Director and/or the<= o:p>

IESG should be aware of? For example, perhaps he or she is uncomforta= ble

with certain parts of the document, or has concerns whether there rea= lly

is a need for it. In any event, if the WG has discussed those issues = and

has indicated that it still wishes to advance the document, detail th= ose

concerns here.

 

  None.

 

 

(7) Has each author confirmed that any and all appropriate IPR

disclosures required for full conformance with the provisions of BCP = 78

and BCP 79 have already been filed. If not, explain why.

 

  Yes.

 

 

(8) Has an IPR disclosure been filed that references this document?

If so, summarize any WG discussion and conclusion regarding the IPR

disclosures.

 

  N/A.

 

 

(9) How solid is the WG consensus behind this document? Does it<= /o:p>

represent the strong concurrence of a few individuals, with others

being silent, or does the WG as a whole understand and agree with it?=

 

  Good consensus across the WG.

 

 

(10) Has anyone threatened an appeal or otherwise indicated extreme

discontent? If so, please summarise the areas of conflict in separate=

email messages to the Responsible Area Director. (It should be in a

separate email because this questionnaire is publicly available.)

 

  No.

 

 

(11) Identify any ID nits the Document Shepherd has found in this

document. (See https://www.ietf.org/tools/idnits/ and the Internet-Dr= afts

Checklist). Boilerplate checks are not enough; this check needs to be=

thorough.

 

  Just a couple of outdated references to other drafts.

 

 

(12) Describe how the document meets any required formal review<= /o:p>

criteria, such as the MIB Doctor, media type, and URI type reviews.

 

  N/A.

 

 

(13) Have all references within this document been identified as=

either normative or informative?

 

  Yes.

 

 

(14) Are there normative references to documents that are not ready f= or

advancement or are otherwise in an unclear state? If such normative

references exist, what is the plan for their completion?

 

  No.

 

 

(15) Are there downward normative references references (see RFC 3967= )?

If so, list these downward references to support the Area Director in=

the Last Call procedure.

 

  No.

 

 

(16) Will publication of this document change the status of any<= /o:p>

existing RFCs? Are those RFCs listed on the title page header, listed=

in the abstract, and discussed in the introduction? If the RFCs are n= ot

listed in the Abstract and Introduction, explain why, and point to th= e

part of the document where the relationship of this document to the

other RFCs is discussed. If this information is not in the document,<= o:p>

explain why the WG considers it unnecessary.

 

  No.

 

 

(17) Describe the Document Shepherd's review of the IANA consideratio= ns

section, especially with regard to its consistency with the body of t= he

document. Confirm that all protocol extensions that the document make= s

are associated with the appropriate reservations in IANA registries.<= o:p>

Confirm that any referenced IANA registries have been clearly

identified. Confirm that newly created IANA registries include a=

detailed specification of the initial contents for the registry, that=

allocations procedures for future registrations are defined, and a

reasonable name for the new registry has been suggested (see RFC 5226= ).

 

  This document does not specify any actions for IANA.

 

 

(18) List any new IANA registries that require Expert Review for futu= re

allocations. Provide any public guidance that the IESG would find

useful in selecting the IANA Experts for these new registries.

 

  N/A.

 

 

(19) Describe reviews and automated checks performed by the Document<= o:p>

Shepherd to validate sections of the document written in a formal

language, such as XML code, BNF rules, MIB definitions, etc.

 

  N/A.

--_000_BY2PR0201MB1910FB93C65CACB34A8B4061840E0BY2PR0201MB1910_-- From nobody Thu Jul 28 11:10:09 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6489312D0EF for ; Thu, 28 Jul 2016 11:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBUjYM22KZUY for ; Thu, 28 Jul 2016 11:10:05 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F33B12D738 for ; Thu, 28 Jul 2016 11:10:05 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id x1so70013575qkb.3 for ; Thu, 28 Jul 2016 11:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eTk8jTufNKWNC/Qhjd1O6iw8keOdMcMdY/mCXSxL0iI=; b=DPIT7XOUKPMBuBrMpIBtsULlfgRgkJC0Attcmp7qA5TDXF49NWlt7IunT89smGdHYj II9J8rLn3/td91QrSJPUSb9nl4WqFSuviN81Z44Tbt9J9Ra8aMJiCoOtdNRmSsyR84yM lzae+fbbgEHBDp0QnDy4zlw2LA+yueAZLIcUsCt5Tesr3b7Be+nv2dcXPFURMrEUIA0a p5pwvP29wEQEK2Tsk3/9KwkvMtkcHL4EOkNTPiTT8pr7GrqDfU3JUgYlS35Y4TL9iw0r oXUMEwyFNwO79peTL0OvOZ1tjHYt905ILPlHYIXCJgjCTdiU0vswuJalItaD5gAhfhch HmEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eTk8jTufNKWNC/Qhjd1O6iw8keOdMcMdY/mCXSxL0iI=; b=LL6ZRXfagQSUEMAmRztTA58rveeH3WLGKMcyfGtB61710JZUkH8cm5Msl2p5H8J2Aj Y6RRGcN+YeZX6IoLpo/4Ur0685A+NkaGA8RJth1Ygd529K9s/Rk6WD4Gcbj9OaXjPwIk D81mMV/WQUyO4gbBpS5ELYdIkSS6SIuTiLkYQrx9LDieTnLnLay5X6PKnm5NCku29AEL e+8UoGbS3qVqlJDYIoyKc/l5rfKD2erxTMrY6fFL62UoJcGOmbCrvzRPWEUeJDs/ZFc3 V2iHX/9m1KLlH3WhR6le8xDrHF1+7BztyNTz7x/PjxlMMkTNw32/YYgPaD48K92qVgcS EqyA== X-Gm-Message-State: AEkooutJBVcxXqGFSSpb/LZDHNW2jjU7Pnobdw4NSQqIDpZyJXgITA/DgFQAk+E476PMFrORu+l/3xZ3EveDaABT X-Received: by 10.55.66.73 with SMTP id p70mr46977736qka.9.1469729404221; Thu, 28 Jul 2016 11:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.53.19 with HTTP; Thu, 28 Jul 2016 11:10:03 -0700 (PDT) In-Reply-To: References: <6628_1466522294_57695AB6_6628_1808_1_9E32478DFA9976438E7A22F69B08FF921BC748AC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <30191_1466690095_576BEA2F_30191_1888_19_9E32478DFA9976438E7A22F69B08FF921BC7C68F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Ina Minei Date: Thu, 28 Jul 2016 11:10:03 -0700 Message-ID: To: Robert Varga Content-Type: multipart/alternative; boundary=001a114ac3120e61d40538b60b25 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:10:07 -0000 --001a114ac3120e61d40538b60b25 Content-Type: text/plain; charset=UTF-8 Yes, ERO is always mandatory, section 6.1 clearly states that. On Mon, Jun 27, 2016 at 4:46 AM, Robert Varga wrote: > On 06/23/2016 03:54 PM, stephane.litkowski@orange.com wrote: > > Hi again, > > > > We also found an issue when a PCC removes a LSP. It would be good to > precise the objects that are mandatory, optional in this case also. > > Some PCE implementations are waiting for an ERO in the PCRpt that > removes an LSP, while some PCC does not send an ERO. > > Would be good to clarify the procedure of LSP removal. > > Hello, > > I think section 6.1 on PCRpt message format covers this: ERO is > mandatory in all cases. I could not find any text which would imply this > should not be the case for R=1. > > Bye, > Robert > > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > > --001a114ac3120e61d40538b60b25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, ERO is always mandatory, section 6.1 clearly states t= hat.=C2=A0

O= n Mon, Jun 27, 2016 at 4:46 AM, Robert Varga <nite@hq.sk> wrote:
On 06/23/2016 03:54 PM, <= a href=3D"mailto:stephane.litkowski@orange.com">stephane.litkowski@orange.c= om wrote:
> Hi again,
>
> We also found an issue when a PCC removes a LSP. It would be good to p= recise the objects that are mandatory, optional in this case also.
> Some PCE implementations are waiting for an ERO in the PCRpt that remo= ves an LSP, while some PCC does not send an ERO.
> Would be good to clarify the procedure of LSP removal.

Hello,

I think section 6.1 on PCRpt message format covers this: ERO is
mandatory in all cases. I could not find any text which would imply this should not be the case for R=3D1.

Bye,
Robert


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


--001a114ac3120e61d40538b60b25-- From nobody Thu Jul 28 11:15:29 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C6712D7E2 for ; Thu, 28 Jul 2016 11:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVAoNWkDWeCv for ; Thu, 28 Jul 2016 11:15:25 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A516312DB76 for ; Thu, 28 Jul 2016 11:15:18 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id x25so53272810qtx.2 for ; Thu, 28 Jul 2016 11:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qCC8S8DkfQmkrQKbFzSxcGIWg4/5kRS7osJCKEY3Si4=; b=Dl1HIXIyYJBe0haXDMMtLlI/w7gTPLs77Hx2g5BtUKoC76P280Sazu2AbEej278qn6 UHg0nj4F6u8Ku16e0F9rVwjKSrqtt8ZconiBaZBjQhVbLCrnbjcX7qJcOZz7eaM0RcTA Ho8CLy4+T1SbywMrl0Ty2zVwjJDW8onKWfvGGAVyiMo5+PtbG33AkBuSjFz2QnhTml1N jap5Q/zr1J9YzhaP6b/6k+7y2OEBacuSE2wzUkiT1AQoGYaY2UnbDCOWUtASB4dr7sil rjaCT+gZyqCB0THG/Hd7wvvhK6G1MWaf4bknpx5nit2mATk8Q8B7AyRk2s0YUm4WCabt kyHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qCC8S8DkfQmkrQKbFzSxcGIWg4/5kRS7osJCKEY3Si4=; b=QvkkLL++VwOYZw/B7T2CzOAl0jh9YcZtmYvYOA4oWfbr7p6RsmqOBhpNTZ9ZWR6FJ4 +zI1/pOCDhvmfOxT5L+SUJycPykMA29UxcdSFxcTUlSYF8J/g8RUlxV2sidbXKgh4yYu 8eoCbYPYfU9YqOMSPR2t8m1wXFYTf7f9rr1vGPnCdS4r8Sr4j5JZg4Rwig58tmq2uCMM HQcTw7jCR1BPl15c6wHQpoG/kFfS5rVfXcMcZwnTf+WgbAVDR7tUgnJs6qlljw/7C1+l unUtjIunCZc8uZaTOZ2e1ciub+Cw/Y8LW9mT8ISM8GcE2Lex4BY/WOChxeLGOddQdETI YhDw== X-Gm-Message-State: AEkoouu1mhTwdUkEMyH/KxfA3cFZskE1jle8tn+6P6d6lodjW41j1BrDPJ8SjcvMPtaSzmoQK+dxmRroTHsoDzN2 X-Received: by 10.237.35.146 with SMTP id j18mr55947999qtc.35.1469729717634; Thu, 28 Jul 2016 11:15:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.53.19 with HTTP; Thu, 28 Jul 2016 11:15:17 -0700 (PDT) In-Reply-To: <23946_1467030052_57711A24_23946_96_1_9E32478DFA9976438E7A22F69B08FF921BC8EF6F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <6628_1466522294_57695AB6_6628_1808_1_9E32478DFA9976438E7A22F69B08FF921BC748AC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1596c2b6-65e5-2a00-ced1-30e39a1a3952@hq.sk> <23946_1467030052_57711A24_23946_96_1_9E32478DFA9976438E7A22F69B08FF921BC8EF6F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Ina Minei Date: Thu, 28 Jul 2016 11:15:17 -0700 Message-ID: To: stephane.litkowski@orange.com Content-Type: multipart/alternative; boundary=001a11377074bcc33d0538b61d2f Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:15:27 -0000 --001a11377074bcc33d0538b61d2f Content-Type: text/plain; charset=UTF-8 Stephane, Thank you for the detailed feedback. How about the following text? The end of synchronization marker is a PCRpt message with the SYNC Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- IDENTIFIERS TLV with the special value of all zeroes. The PCRpt message MUST include an empty ERO as its intended path and SHOULD NOT include the optional RRO object for its actual path. If the PCC has no state to synchronize, it SHOULD only send the end of synchronization marker. On Mon, Jun 27, 2016 at 5:20 AM, wrote: > Hi, > > Thanks for the feedback. > > > The intent here is to use a minimal PCRpt message, hence we explicitly > exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case. > > I think we have not precluded other TLVs from appearing in EOS to allow > future extensions. > > I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves > no purpose and is not required -- section 7.3.1's MUST condition does not > trigger, as > > PLSP-ID=0 is a reserved value and does not identify an LSP. > > Even if you think that LSP-ID should not be carried, it's not explicitly > mentioned in the draft, so it's authorized. > Why not restricting EOS to the minimal case, and let potential future > extensions to modify it ? To you forsee anycase that could require > modification of EOS content ? > > At least the text should use normative words. > > Best Regards, > > Stephane > > -----Original Message----- > From: Robert Varga [mailto:nite@hq.sk] > Sent: Monday, June 27, 2016 14:02 > To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of > Synchronization marker > > On 06/21/2016 05:18 PM, stephane.litkowski@orange.com wrote: > > Hi, > > > > Doing some interop testing between two vendors we falled into > misinterpretation of the current text of the End Of Sync marker content. > > > > Here is the current text : > > > > "The end of synchronization marker is a PCRpt message with the SYNC > > Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved > > value 0 (see Section 7.3). The LSP Object does not include the > > SYMBOLIC-PATH-NAME TLV in this case, it will include an empty ERO as > > its intended path and will not include the optional RRO object in the > > path. If the PCC has no state to synchronize, it will only send the > > end of synchronization marker." > > > > The current text, IMO, has the following issues : > > - it uses non normative wording : "does not include", "will include" , > "will not include". How do we need to interpret it ? MUST, SHOULD, MAY ? > > - it does not precise if it can include or not some other objects : can > it include an LSP-Identifier object (with all fields to 0) ? > > The intent here is to use a minimal PCRpt message, hence we explicitly > exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case. > > I think we have not precluded other TLVs from appearing in EOS to allow > future extensions. > > I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves no > purpose and is not required -- section 7.3.1's MUST condition does not > trigger, as PLSP-ID=0 is a reserved value and does not identify an LSP. > > > It would be good to enhance the text to better describe the content of > EOS. > > > > We suppose that in case there is an issue with the encoding of the EOS > marker, the following behavior will be applied, could you confirm ? > (typically bad encoding of EOS marker) : > > " The PCE does not send positive acknowledgements for properly received > > synchronization messages. It MUST respond with a PCErr message with > > error-type 20 (LSP State Synchronization Error) and error-value 1 > > (indicating an error in processing the PCRpt) (see Section 8.5) if it > > encounters a problem with the LSP State Report it received from the > > PCC and it MUST terminate the session." > > Yes. This would trigger, for example, for PLSP-ID=0 and non-empty ERO. > > Bye, > Robert > > > > _________________________________________________________________________________________________________________________ > > 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 > --001a11377074bcc33d0538b61d2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephane,=C2=A0

Thank you for the detai= led feedback. How about the following text?

The end of = synchronization marker is a PCRpt message with the SYNC Flag set to 0 for a= n LSP Object with PLSP-ID equal to the reserved value 0 (see Section 7.3). = In this case, the LSP Object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV = and SHOULD include the LSP- IDENTIFIERS TLV with the special value of all z= eroes. The PCRpt message MUST include an empty ERO as its intended path and= SHOULD NOT include the optional RRO object for its actual path. If the PCC= has no state to synchronize, it SHOULD only send the end of synchronizatio= n marker.

On= Mon, Jun 27, 2016 at 5:20 AM, <stephane.litkowski@orange.com= > wrote:
Hi,

Thanks for the feedback.

> The intent here is to use a minimal PCRpt message, hence we explicitly= exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same cas= e.
> I think we have not precluded other TLVs from appearing in EOS to allo= w future extensions.
> I do not think LSP-IDENTIFIERS TLV should be carried here, as it serve= s no purpose and is not required -- section 7.3.1's MUST condition does= not trigger, as
> PLSP-ID=3D0 is a reserved value and does not identify an LSP.

Even if you think that LSP-ID should not be carried, it's not ex= plicitly mentioned in the draft, so it's authorized.
Why not restricting EOS to the minimal case, and let potential future exten= sions to modify it ? To you forsee anycase that could require modification = of EOS content ?

At least the text should use normative words.

Best Regards,

Stephane

-----Original Message-----
From: Robert Varga [mailto:nite@hq.sk] Sent: Monday, June 27, 2016 14:02
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.= org
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Sync= hronization marker

On 06/21/2016 05:18 PM, stephane.litkowski@orange.com<= /a> wrote:
> Hi,
>
> Doing some interop testing between two vendors we falled into misinter= pretation of the current text of the End Of Sync marker content.
>
> Here is the current text :
>
> "The end of synchronization marker is a PCRpt message with the SY= NC
>=C2=A0 =C2=A0 Flag set to 0 for an LSP Object with PLSP-ID equal to the= reserved
>=C2=A0 =C2=A0 value 0 (see Section 7.3).=C2=A0 The LSP Object does not = include the
>=C2=A0 =C2=A0 SYMBOLIC-PATH-NAME TLV in this case, it will include an e= mpty ERO as
>=C2=A0 =C2=A0 its intended path and will not include the optional RRO o= bject in the
>=C2=A0 =C2=A0 path.=C2=A0 If the PCC has no state to synchronize, it wi= ll only send the
>=C2=A0 =C2=A0 end of synchronization marker."
>
> The current text, IMO, has the following issues :
> - it uses non normative wording : "does not include", "= will include" , "will not include". How do we need to interp= ret it ? MUST, SHOULD, MAY ?
> - it does not precise if it can include or not some other objects : ca= n it include an LSP-Identifier object (with all fields to 0) ?

The intent here is to use a minimal PCRpt message, hence we explicitly excl= ude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case.
I think we have not precluded other TLVs from appearing in EOS to allow fut= ure extensions.

I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves no = purpose and is not required -- section 7.3.1's MUST condition does not = trigger, as PLSP-ID=3D0 is a reserved value and does not identify an LSP.
> It would be good to enhance the text to better describe the content of= EOS.
>
> We suppose that in case there is an issue with the encoding of the EOS= marker, the following behavior will be applied, could you confirm ? (typic= ally bad encoding of EOS marker) :
> " The PCE does not send positive acknowledgements for properly re= ceived
>=C2=A0 =C2=A0 synchronization messages.=C2=A0 It MUST respond with a PC= Err message with
>=C2=A0 =C2=A0 error-type 20 (LSP State Synchronization Error) and error= -value 1
>=C2=A0 =C2=A0 (indicating an error in processing the PCRpt) (see Sectio= n 8.5) if it
>=C2=A0 =C2=A0 encounters a problem with the LSP State Report it receive= d from the
>=C2=A0 =C2=A0 PCC and it MUST terminate the session."

Yes. This would trigger, for example, for PLSP-ID=3D0 and non-empty ERO.
Bye,
Robert


_______________________= ___________________________________________________________________________= _______________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 message= s 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 inf= ormation 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 dele= te 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

--001a11377074bcc33d0538b61d2f-- From nobody Thu Jul 28 11:23:12 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC0E12DBCD for ; Thu, 28 Jul 2016 11:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNQTC9vUTEL4 for ; Thu, 28 Jul 2016 11:23:08 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4730412DBC1 for ; Thu, 28 Jul 2016 11:23:08 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p74so70361741qka.0 for ; Thu, 28 Jul 2016 11:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yt1RU1cEXcWKeKuv8Qib5LocykXOzntWWd9e01QCPF4=; b=NjypxFtCuz+3n2DEEoNZx8cgqxpZ1hiPuonolw89FddNhYZhmPoBFcilXL22DnjC7v zT87YnOk5ingcFt7X+ANm7FG4vLMMTjOMKkjiU1Yex1wcnWc7aSuJ0l/AUcCIvOl3HHX 7AkPJc99HfhS9M3ZrxrGfS3ifhPTg2kQrqpjFoh7mFGQQ430TG+iKCL4V0Hlk21peXKh xJNFKqQxl5DMhb72hV/DFGc3C87bzjJoBYgkVcIEEetqxvExR9Z6FI1OlOSlHF8JmXdD F0tI+KSUMNjetFJB1YwJXiw80qk8Hn2qR8TaaGPTcnWKqXA4X8WAamHIuRcaYloDAAgB v6Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yt1RU1cEXcWKeKuv8Qib5LocykXOzntWWd9e01QCPF4=; b=bX5A74WHpt9U3hARY9RkaJM8WJDZK/zBq4GYpxV9RNsRR2hey1quOdDyUoNW0ATlwj ezx49Dx+O8IMcNOImjJ2/2059lvXPUFaBkQO34YmALBf8kHQ7nmjyF9RqFTMlM72SLol LOuOgZ5H9FpzviPXP4G0PGwI0bXdB7ZT9HBXACZrYIHzfMAAFxlbOdC7wmNX3RCM+08o V3gA8i3k85ueCV6YfCpeS5KEb6m3P7cQdCj+visykLSl5H4CDOfCfsQyjKyCczh8AzgP 8407zTzzYGYYN4i0y7TAhf92NFyEv/Djj9GoPuFs0rHmaWV7uKCKE0rEKUHaJjgHqdrQ /4IA== X-Gm-Message-State: AEkoout7RF5YRz+kQtx7gEQtnBWNm1XYugm0wxLfFW4e0ATWzXfxU4ey71h8anxRYNDHpCF5I5LMXYoFEBpd97lt X-Received: by 10.55.197.149 with SMTP id k21mr45312854qkl.89.1469730187222; Thu, 28 Jul 2016 11:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.53.19 with HTTP; Thu, 28 Jul 2016 11:23:06 -0700 (PDT) In-Reply-To: References: <6628_1466522294_57695AB6_6628_1808_1_9E32478DFA9976438E7A22F69B08FF921BC748AC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <30191_1466690095_576BEA2F_30191_1888_19_9E32478DFA9976438E7A22F69B08FF921BC7C68F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Ina Minei Date: Thu, 28 Jul 2016 11:23:06 -0700 Message-ID: To: Robert Varga Content-Type: multipart/alternative; boundary=001a1149dc8eba332b0538b639e0 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 18:23:10 -0000 --001a1149dc8eba332b0538b639e0 Content-Type: text/plain; charset=UTF-8 Although section 6.1 shows ERO as mandatory, it doesn't actually state that, how about the following text? "The intended path, represented by the ERO object, is REQUIRED. If the ERO ojbect is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value to be assigned by IANA (ERO object missing). When present, the ERO object SHOULD contain at least one subobject, representing the destination of the LSP." On Thu, Jul 28, 2016 at 11:10 AM, Ina Minei wrote: > Yes, ERO is always mandatory, section 6.1 clearly states that. > > On Mon, Jun 27, 2016 at 4:46 AM, Robert Varga wrote: > >> On 06/23/2016 03:54 PM, stephane.litkowski@orange.com wrote: >> > Hi again, >> > >> > We also found an issue when a PCC removes a LSP. It would be good to >> precise the objects that are mandatory, optional in this case also. >> > Some PCE implementations are waiting for an ERO in the PCRpt that >> removes an LSP, while some PCC does not send an ERO. >> > Would be good to clarify the procedure of LSP removal. >> >> Hello, >> >> I think section 6.1 on PCRpt message format covers this: ERO is >> mandatory in all cases. I could not find any text which would imply this >> should not be the case for R=1. >> >> Bye, >> Robert >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> > --001a1149dc8eba332b0538b639e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Although section 6.1 shows ERO as mandatory, it doesn'= t actually state that, how about the following text?

&qu= ot;The intended path, represented by the ERO object, is REQUIRED. If the ER= O ojbect is missing, the receiving PCE MUST send a PCErr message with Error= -type=3D6 (Mandatory Object missing) and Error-value to be assigned by IANA= (ERO object missing). When present, the ERO object SHOULD contain at least= one subobject, representing the destination of the LSP."
<= div class=3D"gmail_extra">
On Thu, Jul 28, 20= 16 at 11:10 AM, Ina Minei <inaminei@google.com> wrote:
=
Yes, ERO is always mandator= y, section 6.1 clearly states that.=C2=A0
<= br>
On Mon, Jun 27, 2016 a= t 4:46 AM, Robert Varga <nite@hq.sk> wrote:
On 06/23/2016 03:54 PM,= stephan= e.litkowski@orange.com wrote:
> Hi again,
>
> We also found an issue when a PCC removes a LSP. It would be good to p= recise the objects that are mandatory, optional in this case also.
> Some PCE implementations are waiting for an ERO in the PCRpt that remo= ves an LSP, while some PCC does not send an ERO.
> Would be good to clarify the procedure of LSP removal.

Hello,

I think section 6.1 on PCRpt message format covers this: ERO is
mandatory in all cases. I could not find any text which would imply this should not be the case for R=3D1.

Bye,
Robert


__________________________________________= _____
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce



--001a1149dc8eba332b0538b639e0-- From nobody Fri Jul 29 00:37:00 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AD812D196 for ; Fri, 29 Jul 2016 00:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMvGYWrZmcJp for ; Fri, 29 Jul 2016 00:36:55 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id CA71312B04C for ; Fri, 29 Jul 2016 00:36:54 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C8748410247; Fri, 29 Jul 2016 09:36:53 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 5BDDE410242; Fri, 29 Jul 2016 09:36:53 +0200 (CEST) Received: from [10.193.71.24] (10.193.71.24) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Fri, 29 Jul 2016 09:36:52 +0200 To: Ina Minei , References: <6628_1466522294_57695AB6_6628_1808_1_9E32478DFA9976438E7A22F69B08FF921BC748AC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <1596c2b6-65e5-2a00-ced1-30e39a1a3952@hq.sk> <23946_1467030052_57711A24_23946_96_1_9E32478DFA9976438E7A22F69B08FF921BC8EF6F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Olivier Dugeon Organization: Orange Labs Message-ID: <579B0797.6070304@orange.com> Date: Fri, 29 Jul 2016 09:36:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000908070902080509090707" Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 07:36:58 -0000 --------------000908070902080509090707 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Ina, The beginning of our proposal seems OK for me, but the "/MUST include an = empty ERO/" part seems in contradiction with our proposal that specifical= ly mention that an ERO could not be empty. As it concerns the end of the = synchronisation, I think that it is not necessary to include such ERO. Th= e LSP-Identifiers TLV with special values of all zeroes is sufficient. I = would propose to replace the following text: "/The PCRpt message MUST include an empty ERO as its intended path and SH= OULD NOT include the optional RRO object for its actual path./" by "/The PCRpt message MUST NOT include any ERO and RRO objects for its actu= al path./" Indeed, the end marker of synchronisation is composed by a specific LSP w= ith a PLSP-ID equal to 0 and a LSP-IDENTIFIERS TLV with all zeroes. IMHO,= this corresponds to a "/zero LSP/" or "/null LSP/", where there is no ne= ed to attach and ERO or RRO. So, it is not necessary to convey them in th= e PCRpt message. From an algorithm point of view, as the code must includ= e a special test to detect this end marker, it is not a problem to check = that the ERO and RRO are not present, and when they must be present, this= is check by the another branch in the code. Regards Olivier Le 28/07/2016 20:15, Ina Minei a =C3=A9crit : > Stephane,=20 > > Thank you for the detailed feedback. How about the following text? > > The end of synchronization marker is a PCRpt message with the SYNC Flag= set to 0 for an LSP Object with PLSP-ID equal to the reserved value 0 (s= ee Section 7.3). In this case, the LSP Object SHOULD NOT include the SYMB= OLIC-PATH-NAME TLV and SHOULD include the LSP- IDENTIFIERS TLV with the s= pecial value of all zeroes. The PCRpt message MUST include an empty ERO a= s its intended path and SHOULD NOT include the optional RRO object for it= s actual path. If the PCC has no state to synchronize, it SHOULD only sen= d the end of synchronization marker. > > On Mon, Jun 27, 2016 at 5:20 AM, > wrote: > > Hi, > > Thanks for the feedback. > > > The intent here is to use a minimal PCRpt message, hence we expli= citly exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the s= ame case. > > I think we have not precluded other TLVs from appearing in EOS to= allow future extensions. > > I do not think LSP-IDENTIFIERS TLV should be carried here, as it = serves no purpose and is not required -- section 7.3.1's MUST condition d= oes not trigger, as > > PLSP-ID=3D0 is a reserved value and does not identify an LSP. > > Even if you think that LSP-ID should not be carried, it's not expli= citly mentioned in the draft, so it's authorized. > Why not restricting EOS to the minimal case, and let potential futu= re extensions to modify it ? To you forsee anycase that could require mod= ification of EOS content ? > > At least the text should use normative words. > > Best Regards, > > Stephane > > -----Original Message----- > From: Robert Varga [mailto:nite@hq.sk ] > Sent: Monday, June 27, 2016 14:02 > To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org > Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End= Of Synchronization marker > > On 06/21/2016 05:18 PM, stephane.litkowski@orange.com wrote: > > Hi, > > > > Doing some interop testing between two vendors we falled into mis= interpretation of the current text of the End Of Sync marker content. > > > > Here is the current text : > > > > "The end of synchronization marker is a PCRpt message with the SY= NC > > Flag set to 0 for an LSP Object with PLSP-ID equal to the rese= rved > > value 0 (see Section 7.3). The LSP Object does not include th= e > > SYMBOLIC-PATH-NAME TLV in this case, it will include an empty = ERO as > > its intended path and will not include the optional RRO object= in the > > path. If the PCC has no state to synchronize, it will only se= nd the > > end of synchronization marker." > > > > The current text, IMO, has the following issues : > > - it uses non normative wording : "does not include", "will inclu= de" , "will not include". How do we need to interpret it ? MUST, SHOULD, = MAY ? > > - it does not precise if it can include or not some other objects= : can it include an LSP-Identifier object (with all fields to 0) ? > > The intent here is to use a minimal PCRpt message, hence we explici= tly exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the sam= e case. > > I think we have not precluded other TLVs from appearing in EOS to a= llow future extensions. > > I do not think LSP-IDENTIFIERS TLV should be carried here, as it se= rves no purpose and is not required -- section 7.3.1's MUST condition doe= s not trigger, as PLSP-ID=3D0 is a reserved value and does not identify a= n LSP. > > > It would be good to enhance the text to better describe the conte= nt of EOS. > > > > We suppose that in case there is an issue with the encoding of th= e EOS marker, the following behavior will be applied, could you confirm ?= (typically bad encoding of EOS marker) : > > " The PCE does not send positive acknowledgements for properly re= ceived > > synchronization messages. It MUST respond with a PCErr messag= e with > > error-type 20 (LSP State Synchronization Error) and error-valu= e 1 > > (indicating an error in processing the PCRpt) (see Section 8.5= ) if it > > encounters a problem with the LSP State Report it received fro= m the > > PCC and it MUST terminate the session." > > Yes. This would trigger, for example, for PLSP-ID=3D0 and non-empty= ERO. > > Bye, > Robert > > > ___________________________________________________________________= ______________________________________________________ > > 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 a= vez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les mes= sages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. > > This message and its attachments may contain confidential or privil= eged information that may be protected by law; > they should not be distributed, used or copied without authorisatio= n. > 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 ha= ve 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 --------------000908070902080509090707 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Ina,

The beginning of our proposal seems OK for me, but the "M= UST include an empty ERO" part seems in contradiction with our proposal that specifically mention that an ERO could not be empty. As it concerns the end of the synchronisation, I think that it is not necessary to include such ERO. The LSP-Identifiers TLV with special values of all zeroes is sufficient. I would propose to replace the following text:

"The PCRpt message MUST include an empty ERO as its intended path and SHOULD NOT include the optional RRO object for its actual path."

by

"The PCRpt message MUST NOT include any ERO and RRO objects for its actual path."

Indeed, the end marker of synchronisation is composed by a specific LSP with a PLSP-ID equal to 0 and a LSP-IDENTIFIERS TLV with all zeroes. IMHO, this corresponds to a "zero LSP" or "null LSP", where there is no need to attach and ERO or RRO. So, it is not necessary to convey them in the PCRpt message. From an algorithm point of view, as the code must include a special test to detect this end marker, it is not a problem to check that the ERO and RRO are not present, and when they must be present, this is check by the another branch in the code.

Regards

Olivier


Le 28/07/2016 20:15, Ina Minei a =C3=A9crit=C2=A0:
Stephane,=C2=A0

Thank you for the detailed feedback. How about the following text?

The end of synchronization marker is a PCRpt message with the SYNC Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- IDENTIFIERS TLV with the special value of all zeroes. The PCRpt message MUST include an empty ERO as its intended path and SHOULD NOT include the optional RRO object for its actual path. If the PCC has no state to synchronize, it SHOULD only send the end of synchronization marker.

On Mon, Jun 27, 2016 at 5:20 AM, <stephane.litkowski@orange.com> wrote:
Hi,

Thanks for the feedback.

> The intent here is to use a minimal PCRpt message, hence we explicitly exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case.
> I think we have not precluded other TLVs from appearing in EOS to allow future extensions.
> I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves no purpose and is not required -- section 7.3.1's MUST condition does not trigger, as
> PLSP-ID=3D0 is a reserved value and does not identify an LSP.

Even if you think that LSP-ID should not be carried, it's not explicitly mentioned in the draft, so it's authorized.
Why not restricting EOS to the minimal case, and let potential future extensions to modify it ? To you forsee anycase that could require modification of EOS content ?

At least the text should use normative words.

Best Regards,

Stephane

-----Original Message-----
From: Robert Varga [mailto:nite@hq.sk]
Sent: Monday, June 27, 2016 14:02
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.= org
Subject: Re: [Pce] draft-ietf-pce-stateful-pce : clarifying the End Of Synchronization marker
On 06/21/2016 05:18 PM, = stephane.litkowski@orange.com wrote:
> Hi,
>
> Doing some interop testing between two vendors we falled into misinterpretation of the current text of the End Of Sync marker content.
>
> Here is the current text :
>
> "The end of synchronization marker is a PCRpt message with the SYNC
>=C2=A0 =C2=A0 Flag set to 0 for an LSP Object with PL= SP-ID equal to the reserved
>=C2=A0 =C2=A0 value 0 (see Section 7.3).=C2=A0 The LS= P Object does not include the
>=C2=A0 =C2=A0 SYMBOLIC-PATH-NAME TLV in this case, it= will include an empty ERO as
>=C2=A0 =C2=A0 its intended path and will not include = the optional RRO object in the
>=C2=A0 =C2=A0 path.=C2=A0 If the PCC has no state to = synchronize, it will only send the
>=C2=A0 =C2=A0 end of synchronization marker."
>
> The current text, IMO, has the following issues : > - it uses non normative wording : "does not include", "will include" , "will not include". How do we need to interpret it ? MUST, SHOULD, MAY ?
> - it does not precise if it can include or not some other objects : can it include an LSP-Identifier object (with all fields to 0) ?

The intent here is to use a minimal PCRpt message, hence we explicitly exclude SYMBOLIC-PATH-NAME TLV and RRO. ERO is kept empty for the same case.

I think we have not precluded other TLVs from appearing in EOS to allow future extensions.

I do not think LSP-IDENTIFIERS TLV should be carried here, as it serves no purpose and is not required -- section 7.3.1's MUST condition does not trigger, as PLSP-ID=3D0 is a reserved value and does not identify an LSP.

> It would be good to enhance the text to better describe the content of EOS.
>
> We suppose that in case there is an issue with the encoding of the EOS marker, the following behavior will be applied, could you confirm ? (typically bad encoding of EOS marker) :
> " The PCE does not send positive acknowledgements for properly received
>=C2=A0 =C2=A0 synchronization messages.=C2=A0 It MUST= respond with a PCErr message with
>=C2=A0 =C2=A0 error-type 20 (LSP State Synchronizatio= n Error) and error-value 1
>=C2=A0 =C2=A0 (indicating an error in processing the = PCRpt) (see Section 8.5) if it
>=C2=A0 =C2=A0 encounters a problem with the LSP State= Report it received from the
>=C2=A0 =C2=A0 PCC and it MUST terminate the session."=

Yes. This would trigger, for example, for PLSP-ID=3D0 and= non-empty ERO.

Bye,
Robert


_________________________________________= _________________________________________________________________________= _______

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.o= rg/mailman/listinfo/pce



_______________________________________________
Pce mailing list
Pce@ie=
tf.org
https://www.ietf.org/mailman/listinfo/pce

--------------000908070902080509090707-- From nobody Fri Jul 29 02:16:14 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADB312D813; Fri, 29 Jul 2016 02:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.287, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZYUOVs8rei9; Fri, 29 Jul 2016 02:16:10 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [161.106.1.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1812D740; Fri, 29 Jul 2016 02:16:09 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20D3F410247; Fri, 29 Jul 2016 11:16:08 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by p-mail1.rd.orange.com (Postfix) with ESMTP id B90EF410240; Fri, 29 Jul 2016 11:16:07 +0200 (CEST) Received: from [10.193.71.154] (10.193.71.154) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.301.0; Fri, 29 Jul 2016 11:16:07 +0200 From: Julien Meuric To: Organization: Orange Message-ID: <579B1ED7.6030006@orange.com> Date: Fri, 29 Jul 2016 11:16:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Shepherd's Review of draft-ietf-pce-pce-initiated-lsp-07 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 09:16:12 -0000 Dear authors of draft-ietf-pce-pce-initiated-lsp, Please find below my shepherd's review of the aforementioned I-D. _Summary_ The document does not need much work to move forward. As discussed with Ina during the IETF week, a few items deserve to be highlighted: - the choice of zero as wildcard PLSP-ID to remove all LSPs initiated by a PCE is unsafe; - the use of the END-POINTS object is misaligned with RFC 5440's definition and not suited to SR. _Detailed Comments_ ------ Header --- - Like with draft-ietf-pce-stateful-pce, adding "Individual Contributor" after Ed's name helps getting rid of the odd empty line. ------ Abstract --- - s/provide stateful control/provide active control/ ------ Section 1. --- - s/Path Computation Element Protocol PCEP/Path Computation Element communication Protocol (PCEP)/ ------ Section 3. --- - s/provides stateful control/provides active control/ - s/is one of a software-driven/is a software-driven/ - s/is one of dynamically/is dynamically/ - s/is that of demand/is demand/ - s/Operation overview/Operation Overview/ - s/PCE provisioned/PCE-provisioned/ - s/it also generates/it MUST also generate/ - s/PCC also sets/PCC MUST also set/ - s/PCE may update/PCE MAY update/ - s/PCC initiated LSPs/PCC-initiated LSPs/ ------ Section 4. --- - s/PCE provisioned/PCE-provisioned/ ------ Section 5. --- - s/LSP instantiation and deletion/LSP Instantiation and Deletion/ - OLD: A Path Computation LSP Initiate Message (also referred to as PCInitiate message) is a PCEP message... NEW: A Path Computation LSP Initiate Message is referred to as PCInitiate message: it is a PCEP message... - s/and may contain/and MAY contain/ - OLD : If the SRP object is missing, the PCC MUST send a PCErr with error-type 6 (Mandatory Object missing) and error-value=10 (SRP Object missing) (per [I-D.ietf-pce-stateful-pce]. If the LSP object is missing, the PCC MUST send a PCErr with error-type 6 (Mandatory Object missing) and error-value=8 (LSP Object missing) (per [I-D.ietf-pce-stateful-pce]). NEW: Missing SRP and LSP objects in PCInitiate MUST trigger the same PCErr procedures as specified in [I-D.ietf-pce-stateful-pce] for PCUpd. - s//[]/ (see discussion below) - s/5.3. LSP instantiation/5.3. LSP Instantiation/ - s/LSP Initiate Message/PCInitiate message/ - s/results in a PCErr/MUST result in a PCErr/ - The use of the END-POINTS objects has puzzled me for multiple reasons: * RFC 5440 defines the object as a pair of IDs allowing to identify the two points to be interconnected by the ERO to be filled in, whereas the draft uses it to push the IDs of the signaling ends; * The signaling source ID to be used should rather be up to the PCC, the requirement on pushing it from the PCE is not obvious; * The ERO may include some IDs that could be used as default source/destination IDs, which also makes the need for a destination ID less obvious; * To address these, I see 3 options: 1- Giving up the use of a specific object and fully rely on the ERO; 2- Defining new "SignalingRemoteID" types (possibly within the END-POINTS object class) to (optionally) convey the info; 3- Rephrase the text to turn the unwanted "redefinition" of the END-POINTS object into a wording more consistent with RFC 5440, e.g.: OLD: The END-POINTS Object is mandatory for an instantiation request of an RSVP-signaled LSP. It contains the source and destination addresses for provisioning the LSP. If the END-POINTS Object is missing, the PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=3 (END-POINTS Object missing). NEW: For an instantiation request of an RSVP-signaled LSP, the destination address may be needed. The PCC may determine it from a provided object (e.g., ERO) or a local decision. Alternatively, the END-POINTS object MAY be included to explicitly convey the destination addresses to be used in the RSVP-TE signaling. The source address may be either specified or left up to the PCC decision using the 0.0.0.0 value. For LSPs to be setup by other means (e.g., Segment Routing), the END-POINTS object SHOULD be omitted. * In case you go for option 2, you still need to be more explicit on the non-RSVP case; i.e., the new text should say: "The MAY be included for instantiation request of an RSVP-TE-signaled LSP, and SHOULD be omitted otherwise." - s/echo the SRP-id-number/echo the SRP-ID-number/ - The 2nd paragraph on page 11 ("On succesful completion...") duplicates the 2nd one on page 10 ("The PCE MAY include...") and should be dropped (or at least the 2nd half of it). - s/succesful completion/successful completion/ - s/5.3.1. The Create flag/5.3.1. The Create Flag/ - On Figure 3, the "O" would be better in the middle of the 3-bit field. - Once defined, the phrases "Create flag"/"C Flag"/"C-flag" are alternatively used, please pick one and use it everywhere (I personally like "C-flag" but "R flag" seems common in the I-D). Note that flag-phrases should be consistent beyond C. - s/the PCE who initiated/the PCE which initiated/ - s/5.4. LSP deletion/5.4. LSP Deletion/ - "A PLSP-ID of zero removes all LSPs...": a broken implementation is very likely to use 0 as a default, any value but 0 would be safer; please pick another one. - s/value 1 ([I-D.ietf-pce-stateful-pce ])/value 1 as per [I-D.ietf-pce-stateful-pce ])/ - s/The R flag [...] SHOULD be set./The R flag [...] MUST be set./ [or with "R-flag" ?] ------ Section 6. --- - s/LSP delegation and cleanup/LSP Delegation and Cleanup/ - s/must have the delegation bit/MUST have the delegation bit/ - OLD: Receipt of a PCInitiate message with a non-zero PLSP-ID normally results in the generation of a PCErr. If the LSP is an orphan, the PCC MUST NOT generate an error and MUST redelegate the LSP to the PCE. NEW: On receipt of PCInitiate message with a PLSP-ID pointing to an orphan LSP, the PCC MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST result in the generation of a PCErr. ------ Section 7. --- - s/7. Implementation status/7. Implementation Status/ ------ Section 8. --- - s/8. IANA considerations/8. IANA Considerations/ ------ Section 11. --- - The reference to draft-ietf-pce-stateful-sync-optimizations is not required to understand this document and should thus be moved to the informative section. - Ditto for RFC 5226 (guidelines for authors, not mandatory to readers). ------ Cheers, Julien