Re: [Pce] IPR poll for draft-dhodylee-pce-pcep-ls

[Daniele Ceccarelli]

Hi Andrew,

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

Thanks
Daniele

Il Ven 5 Apr 2024, 17:14 Andrew Stone (Nokia)  ha
scritto:

> Hi Authors,
>
> In preparation for WG adoption on this draft, we'd like all authors and
> contributors to confirm on the list that they are in compliance with IETF
> IPR rules.
>
> Please respond (copying the mailing list) to say one of:
>
> - I am not aware of any IPR applicable to this draft that should be
> disclosed in accordance with IETF IPR rules.
>
>
>
> - I am aware of the IPR applicable to this draft, and it has already been
> disclosed to the IETF.
>
>
>
> - I am aware of IPR applicable to this draft, but that has not yet been
> disclosed to the IETF. I will work to ensure that it will be disclosed in a
> timely manner.
>
>
>
> Thanks,
>
> Andrew
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll for draft-ietf-pce-vn-association-05

[Daniele Ceccarelli]

Hi Dhruv, all,

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

BR
Daniele

From: Dhruv Dhody 
Sent: den 22 februari 2022 13:24
To: Young Lee ; zhenghaom...@huawei.com; Daniele 
Ceccarelli 
Cc: pce@ietf.org; pce-chairs 
Subject: IPR Poll for draft-ietf-pce-vn-association-05

Hi Authors,

In preparation for WG LC on this draft, I'd like all authors to confirm on the 
list that they are in compliance with IETF IPR rules for 
https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/

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

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

I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been disclosed 
to the IETF. I will work to ensure that it will be disclosed in a timely manner.

Thanks,
Dhruv

PS. Note that one IPR has been disclosed - 
https://datatracker.ietf.org/ipr/3329/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

[Daniele Ceccarelli]

Hi WG,

In CCAMP we’re obviously very interested in this draft.
I reviewed it before the last call and expressed my support, which is still 
valid for the latest version.

BR
Daniele

From: Pce  On Behalf Of Dhruv Dhody
Sent: den 18 januari 2022 14:17
To: pce@ietf.org
Cc: draft-ietf-pce-pcep-stateful-pce-gm...@ietf.org; pce-chairs 

Subject: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-stateful-pce-gmpls-16 [1].  Please indicate your support or 
concern for this draft. If you are opposed to the progression of the draft to 
RFC, please articulate your concern. If you support it, please indicate that 
you have read the latest version and it is ready for publication in your 
opinion. As always, review comments and nits are most welcome.

The WG LC will end on 1st Feb 2022.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04

[Daniele Ceccarelli]

Hi Dhruv, Julien,

Thanks for extending the deadline. 
I support the adoption of the draft. Inter domain stateful PCE capabilities are 
extremely important in the provisioning of end to end services. (tried a work 
around to avoid mentioning network slicing) .

BR
Daniele  

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: den 12 januari 2021 11:38
To: pce@ietf.org
Cc: pce-chairs 
Subject: Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04

Hi WG,

The response has been limited so far. Thanks to Oliver for responding to the 
comments.

Since the adoption period coincided with holidays, we are extending the 
adoption call for another week (i.e. Monday 18th Jan). We *need* to hear from 
more of you before taking a call. Please respond with your support (or not) for 
this work and if this I-D is a good basis to be further refined under the 
control of the WG.

Regards,
Dhruv

On Fri, Jan 8, 2021 at 2:57 PM Dhruv Dhody  wrote:
>
> Hi WG,
>
> Happy New Year!
>
> Just a reminder, the WG Adoption poll ends on Monday 11th Jan, please 
> respond to the call with your support (or not), comments, etc.
> Please be more vocal on the list [1].
>
> Thanks!
> Dhruv & Julien
>
> [1] 
> https://datatracker.ietf.org/meeting/109/materials/slides-109-pce-1-in
> troduction-01
> > Please be Vocal
> >
> > o During WG Adoption and WG LC calls, the response is less.
> >
> > o Please be vocal on the list to help us gauge the consensus better.
> >
> > o The working group mailing lists are looked at by the IESG, IAB, and 
> > others (internal and external to IETF) to determine interest/participation 
> > level in our standards process.
> >
> > o Please review ideas from your peers, these are community outputs of the 
> > working group as a whole.
> >
>
> On Fri, Dec 18, 2020 at 6:22 PM Dhruv Dhody  wrote:
> >
> > Hi WG,
> >
> > This email begins the WG adoption poll for 
> > draft-dugeon-pce-stateful-interdomain-04.
> >
> > https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful-inte
> > rdomain-04
> >
> > Should this draft be adopted by the PCE WG? Please state your 
> > reasons
> > - Why / Why not? What needs to be fixed before or after adoption? 
> > Are you willing to work on this draft? Review comments should be 
> > posted to the list.
> >
> > To accommodate for the holiday season, this adoption poll will end 
> > on 11th Jan 2021 (Monday).
> >
> > Thanks!
> > Dhruv

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

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

Re: [Pce] IPR Poll on draft-dugeon-pce-stateful-interdomain-04

[Daniele Ceccarelli]

Hi Hari,


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

in accordance with IETF IPR rules.

BR
Daniele

From: Hariharan Ananthakrishnan 
Sent: den 18 december 2020 23:12
To: olivier.dug...@orange-ftgroup.com; Julien Meuric 
; Daniele Ceccarelli 
; younglee...@gmail.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-dugeon-pce-stateful-interdomain-04


Hi Authors,



In preparation for WG adoption on this draft, I'd like all

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

with IETF IPR rules.

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

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

in accordance with IETF IPR rules.



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

disclosed to the IETF.



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

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

timely manner.



Thanks,

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

Re: [Pce] IPR Poll on draft-ietf-pce-stateful-pce-lsp-scheduling

[Daniele Ceccarelli]

Hi,



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



BR

Daniele



From: Hariharan Ananthakrishnan 
Sent: den 5 december 2019 18:13
To: Huaimo Chen ; Zhuangyan (Yan) 
; bill...@huawei.com; Daniele Ceccarelli 

Cc: pce@ietf.org
Subject: IPR Poll on draft-ietf-pce-stateful-pce-lsp-scheduling



Hi Authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

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

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

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari


smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE WG Adoption poll for draft-leedhody-pce-vn-association

[Daniele Ceccarelli]

Yes/Support.



BR



Daniele



From: Young Lee 
Sent: den 14 juli 2019 22:27
To: adr...@olddog.co.uk
Cc: pce@ietf.org; draft-leedhody-pce-vn-associat...@ietf.org
Subject: Re: PCE WG Adoption poll for draft-leedhody-pce-vn-association



Yes/Support.



Young (co-author)



On Sun, Jul 14, 2019, 8:00 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Hi WG,

He authors of draft-leedhody-pce-vn-association have been asking for
adoption and...

- the base PCEP association extensions seem to be stable and advancing
- I did an early review and the authors span a new version

So, this starts an adoption poll for the draft. Because IETF-105 is imminent
and you all have lots to do and read, we'll make this a three week poll
ending on 4th August.

Please send your comments of support or antipathy.

In either case, please indicate whether or not you have read the draft, and
if you support it, please say whether or not you propose to and even
possibly implement the draft.

Many thanks,
Adrian (for the chairs)



smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll on draft-leedhody-pce-vn-association

[Daniele Ceccarelli]

Hi,

 

No i’m not aware of any IPR.

BR

 

Daniele  

 

From: Hariharan Ananthakrishnan  
Sent: den 15 juli 2019 11:27
To: younglee...@gmail.com; zhang.x...@huawei.com; Daniele Ceccarelli 

Cc: pce@ietf.org
Subject: IPR poll on draft-leedhody-pce-vn-association

 

Hi Authors,
 
In preparation for Working Group adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.
One IPR has already been disclosed:  <https://datatracker.ietf.org/ipr/3329/> 
https://datatracker.ietf.org/ipr/3329/
Please respond (copying the mailing list) to say one of:
 
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
 
I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.
 
I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.
 
Thanks,
- Hari


smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Reminder: Working Group last call on draft-ietf-pce-stateful-hpce-06

[Daniele Ceccarelli]

Same here...and I couldn’t explain it better than Ramon.

 

BR

 

Daniele  

 

From: Pce  On Behalf Of Ramon Casellas
Sent: den 1 april 2019 09:46
To: pce@ietf.org
Subject: Re: [Pce] Reminder: Working Group last call on 
draft-ietf-pce-stateful-hpce-06

 

Hi all

Apologies for the delay in my response. 

I have read the draft, and I support its progression. In the framework of 
several research projects, we have been considering, implementing and testing 
stateful hierarchical PCE for optical networks and this draft describes the 
general considerations for the applicability of stateful HPCE in a multi-domain 
network. 

I also think it is a good companion document to the work on ACTN being done in 
the TEAS WG

Best regards

Ramon

 

On 01/04/2019 9:34, Adrian Farrel wrote:

So far you have all been very quiet.
 
Thanks,
Adrian
 
-Original Message-
From: Pce    On Behalf Of 
Adrian Farrel
Sent: 13 March 2019 22:01
To: pce@ietf.org  
Subject: [Pce] Working Group last call on draft-ietf-pce-stateful-hpce-06
 
Hi working group,
 
This email starts a working group last call for
draft-ietf-pce-stateful-hpce-06.
 
I would like to hear messages of support or concern about this draft.
 
If you support its progression towards publication as an RFC, please let us
know that you have read the latest revision, and explain why you think the
work is important. Indications of implementation would also be welcome -
although this document is informational, I believe some people may have
built stateful hierarchical PCEs for experimentation or deployment.
 
If you are opposed to the progression or have concerns please articulate
them.
 
As always, review comments and nits are most welcome.
 
Because of the effort that is going in to preparing for IETF-104 and because
of the time spent away, this last call will run for three weeks and end on
April 4th.
 
Thanks,
Adrian
 
___
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

-- 
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division
Optical Networks and Systems Department -- http://networks.cttc.es/ons
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01


smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR poll on draft-ietf-pce-stateful-hpce

[Daniele Ceccarelli]

Hi Adrian, WG,

I'm not aware of any IPR applicable to this draft.
BR

Daniele  

-Original Message-
From: Leeyoung  
Sent: den 13 mars 2019 14:53
To: adr...@olddog.co.uk; draft-ietf-pce-stateful-h...@ietf.org;
s.avantika.avant...@gmail.com; Zhangxian (Xian) ;
udayasreere...@gmail.com
Cc: pce@ietf.org
Subject: RE: IPR poll on draft-ietf-pce-stateful-hpce

Hi Adrian,

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

Thanks.
Young

-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: Wednesday, March 13, 2019 7:32 AM
To: draft-ietf-pce-stateful-h...@ietf.org; s.avantika.avant...@gmail.com;
Zhangxian (Xian) ; udayasreere...@gmail.com
Cc: pce@ietf.org
Subject: IPR poll on draft-ietf-pce-stateful-hpce

Hi authors,

In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

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

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

I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
Adrian



smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption poll for draft-lee-pce-flexible-grid

[Daniele Ceccarelli]

Hi Adrian,

Yes i support the adoption of the document. This is needed to complete the
work done by CCAMP on flexi grid.

Thanks,

Daniele  

-Original Message-
From: Pce  On Behalf Of Italo Busi
Sent: den 11 februari 2019 17:10
To: pce@ietf.org
Subject: Re: [Pce] Adoption poll for draft-lee-pce-flexible-grid

Hi Adrian, PCE WG,

Yes/Support. We have a plan for implementation for this.

I think this work is useful and complementary to the on-going work in CCAMP
to cover the cases where networks are using PCEP

Italo

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, February 5, 2019 8:16 AM
To: pce@ietf.org
Subject: [Pce] Adoption poll for draft-lee-pce-flexible-grid

Hi WG,

Please read and review draft-lee-pce-flexible-grid-03 and send your comments
to the mailing list.

Should we adopt it? Why / why not?

What needs to be fixed before/after adoption?

Is this a draft you would be willing to work on? Do you plan to implement?

This poll will run until 20th February.

Thanks,
PCE Chairs

___
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

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


smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Checking for IPR on draft-ietf-pce-applicability-actn

[Daniele Ceccarelli]

Hi Adrian,

"No, I am not aware of any IPR applicable to this draft"

Thanks,

Daniele  

-Original Message-
From: Adrian Farrel  
Sent: den 8 februari 2019 12:38
To: dhruv.i...@gmail.com; leeyo...@huawei.com; Daniele Ceccarelli

Cc: pce@ietf.org
Subject: Checking for IPR on draft-ietf-pce-applicability-actn

 Hi,

As we take this document through WG last call, it would be helpful if you
could confirm the situation with regard to IPR that might apply to the
draft.

I see that none has so far been disclosed. 

Could you answer:

"No, I am not aware of any IPR applicable to this draft"

Or

"Yes, I am aware of IPR applicable to this draft and will ensure that it
will be disclosed as soon as possible."

Thanks,
Adrian



smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Regarding IPR on draft-lee-pce-flexible-grid-03

[Daniele Ceccarelli]

Hi Adrian,

No, I'm not aware of any IPR that applies to this draft

BR
Daniele  

-Original Message-
From: Adrian Farrel  
Sent: den 5 februari 2019 15:05
To: leeyo...@huawei.com; zhenghaom...@huawei.com; ramon.casel...@cttc.es;
Ricard Vilalta ; Daniele Ceccarelli
; Francesco Lazzeri

Cc: pce@ietf.org
Subject: Regarding IPR on draft-lee-pce-flexible-grid-03

Authors, Contributors, WG,

As part of preparation for WG Adoption:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see
RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are aware
of any relevant IPR. This document will not advance to the next stage until
a response has been received from each author and listed contributor. NOTE:
THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as
an author or contributor, we remind you of your obligations under the IETF
IPR rules which encourages you to notify the IETF if you are aware of IPR of
others on an IETF contribution, or to refrain from participating in any
contribution or discussion related to your undisclosed IPR. For more
information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
PCE WG Chairs

PS Please include all listed in the headers of this message in your
response.



smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Replacing Jon as PCE Co-Chair

[Daniele Ceccarelli]

Thanks a lot Jon…double thumb up!...and good luck for the future.

Good luck also to Dhruv, you’ll need it…and you deserve to take this role for 
the excellent work done so far as secretary and WG member (driver).

 

Adrian, you’re starting the second round? What’s next…CCAMP chair and RTG AD ? 
…Deborah we’re screwed 

 

Daniele  

 

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of BRUNGARD, DEBORAH A
Sent: Tuesday, January 29, 2019 12:13 AM
To: pce@ietf.org  
Cc: mailto:rtg-...@ietf.org> > (rtg-...@ietf.org 
 ) mailto:rtg-...@ietf.org> >; 
pce-cha...@ietf.org  
Subject: [Pce] Replacing Jon as PCE Co-Chair

 

Hi PCEers,

 

As announced at IETF103, Jon Hardwick has requested to step down as PCE 
Co-Chair. We thank him for his many years of service and wish him all the best!

 

As Jon is very difficult to replace and to help Julien over these next several 
months, I’ve decided to replace Jon with two Co-Chairs: Dhruv Dhody and Adrian 
Farrel. 

 

Dhruv is one of our top lead technical contributors in PCE and he is currently 
the PCE secretary. I am sure he will be fantastic in his new role as Co-Chair. 
The difficulty is that he is a co-author on a high proportion of the PCE drafts 
and that is not a good thing for a Chair as it will severely burden the other 
Co-Chair with managing those documents. Because of this difficulty, I’ve asked 
Dhruv to re-allocate authorship on a majority of his drafts as quickly as 
possible. Dhruv has agreed.

 

While Dhruv is learning the ropes of being a Chair and re-distributing his 
drafts, I’ve asked Adrian to help. Adrian, of course, is well known to all of 
us. No introduction needed

 

It is expected Adrian will only be needed for approximately 4 months.

 

Welcome to both Dhruv and Adrian!

 

Thanks!

Deborah

 



smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-auto-bandwidth

[Daniele Ceccarelli]

Hi Julien, WG,

I've reviewed the document as well. in my opinion it is a good shape and ready 
to be moved forward.

BR
Daniele

Il 18 Dic 2018 7:52 AM, "Chengli (Cheng Li)"  ha scritto:
Hi WG,

Yes, support.  I've reviewed this document and believe it is ready for 
publication.

Thanks,
Cheng


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: Thursday, December 13, 2018 9:30 PM
To: pce@ietf.org
Subject: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-auto-bandwidth

Hi all,

This e-mail starts a 3-week PCE WG Last Call on 
draft-ietf-pce-stateful-pce-auto-bandwidth-08. Please share your reviews and 
comments using the mailing list by Friday January 5, 2019.

Thank you,

Julien

___
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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption Poll for draft-lazzeri-pce-residual-bw

[Daniele Ceccarelli]

Hi Julien,

Thanks for starting this. I believe the feedbacks collected after the first
discussions significantly improved the scope of the draft, making it narrow,
simple and straight forward.
This is a minor extension to PCEP that allows a better exchange of path
computation results, particularly in an hierarchical environment.
Yes, I would be happy to see this work proceeding.

Thanks,
Daniele  

-Original Message-
From: Pce  On Behalf Of Julien Meuric
Sent: den 13 december 2018 14:05
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-lazzeri-pce-residual-bw

Dear WG,

We discussed about draft-lazzeri-pce-residual-bw a couple of times during
past IETF meetings. At that time, those in the room who had read it looked
quite interested, but they were just a few. We now request a feedback from
the list: do you support the adoption of draft-lazzeri-pce-residual-bw as a
starting point for a PCE work item?
(https://tools.ietf.org/html/draft-lazzeri-pce-residual-bw-01)

Please respond to the list, including your reasons if you do not support.

Thanks

Julien


P.S.: We are aware that the latest version of the I-D has expired, but an
adoption would solve that and a lack of interest may help the authors focus
their effort on something else than a simple timer reset.

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


smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08

[Daniele Ceccarelli]

Yes/support.

I think the topic is very relevant for the industry in these days and this 
draft is a good starting point for WG to work on.

BR
Daniele


-- Forwarded message -
From: Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>>
Date: Sat, Oct 13, 2018 at 8:27 PM
Subject: WG adoption poll for 
draft-zhao-pce-pcep-extension-for-pce-controller-08
To: pce@ietf.org mailto:pce@ietf.org>>
Cc: 
draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org
 
mailto:draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org>>,
 pce-cha...@ietf.org 
mailto:pce-cha...@ietf.org>>

This is the start of a two week poll on making 
draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/

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 Friday, October 26.

Many thanks,

Jon and Julien

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

Re: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03

[Daniele Ceccarelli]

Yes/support

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: martedì 20 febbraio 2018 14:48
To: Jonathan Hardwick 
Cc: pce@ietf.org; draft-li-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03

Yes/Support!

Regards,
Dhruv (co-author)

On Tue, Feb 20, 2018 at 7:04 PM, Jonathan Hardwick 
> 
wrote:
Dear PCE WG

This is the start of a two week poll on making draft-li-pce-pcep-flowspec-03 a 
PCE working group document.
https://datatracker.ietf.org/doc/draft-li-pce-pcep-flowspec/

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, March 6.

Many thanks,

Jon and Julien


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

Re: [Pce] RtgDir review: draft-ietf-pce-lsp-setup-type-07

[Daniele Ceccarelli]

Hi Jon,

thanks for considering my feedbacks. It’s pointless to reply inline as it would 
be an OK to all you changes, let’s bundle it here 

Thanks,
Daniele

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: lunedì 15 gennaio 2018 15:43
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>; <rtg-...@ietf.org> 
(rtg-...@ietf.org) <rtg-...@ietf.org>
Cc: rtg-...@ietf.org; pce@ietf.org; draft-ietf-pce-lsp-setup-type@ietf.org
Subject: RE: RtgDir review: draft-ietf-pce-lsp-setup-type-07

Hi Daniele

Many thanks for the review.  Please see my replies below in  … .

Best regards
Jon


From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
Sent: 10 January 2018 10:41
To: <rtg-...@ietf.org<mailto:rtg-...@ietf.org>> 
(rtg-...@ietf.org<mailto:rtg-...@ietf.org>) 
<rtg-...@ietf.org<mailto:rtg-...@ietf.org>>
Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; 
pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-lsp-setup-type@ietf.org<mailto:draft-ietf-pce-lsp-setup-type@ietf.org>
Subject: RtgDir review: draft-ietf-pce-lsp-setup-type-07


Hello,



I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.



Document: draft-ietf-pce-lsp-setup-type-07

Reviewer: Daniele Ceccarelli

Review Date: 2018-01-10

IETF LC End Date: date-if-known

Intended Status: Standards Track



Summary:

I have some minor concerns about this document that I think should be resolved 
before publication.



Comments:

The draft is a bit confusing on some aspects. I had to read it again a couple 
of times to understand that 2 TLVs are defined (probably my fault). If you 
could make it clearer in the intro that 2 TLVs are defined each of which with a 
precise scope, that would make things easier.



 How about I add the following in between the second and third paragraphs 
of the introduction?



NEW
   So far, PCEP and its extensions have assumed that the TE paths are
   label switched and are established via the RSVP-TE protocol.
   However, other methods of LSP setup are possible in the PCE
   architecture (see [RFC4655] and [RFC4657]).  This document generalizes
   PCEP to allow other LSP setup methods to be used.  It defines two new
   TLVs, as follows.
  -  The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to
  announce which LSP setup methods it supports.
  -  The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify
  which setup method should be used for a given LSP.

END NEW



I’ll then tweak the remaining paragraphs in the introduction to fit in with 
this preamble.  Does that sound OK?





Also the list of the PSTs is a bit confusing. Since each PST is a byte field 
why don’t you adopt and encoding like the one used in RFC7138 section 4.1.1. 
for the muxing stages? You could encode the PST values like the Stage#1…Stage# 
below.


   0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type = 1 (Unres-fix)   | Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  | Num of stages |T|S| TSG | Res |Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Stage#1|  ...  |   Stage#N |Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 0| . |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 7| Unreserved Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: Bandwidth Sub-TLV -- Type 1



 The PST encoding is like the example you quoted i.e. a list of bytes 
padded with zeros plus a field saying how many PSTs are in the list.  If I 
re-draw the diagram like this, does it look better to you?


   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

[Pce] RtgDir review: draft-ietf-pce-lsp-setup-type-07

[Daniele Ceccarelli]

Hello,



I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.



Document: draft-ietf-pce-lsp-setup-type-07

Reviewer: Daniele Ceccarelli

Review Date: 2018-01-10

IETF LC End Date: date-if-known

Intended Status: Standards Track



Summary:

I have some minor concerns about this document that I think should be resolved 
before publication.



Comments:

The draft is a bit confusing on some aspects. I had to read it again a couple 
of times to understand that 2 TLVs are defined (probably my fault). If you 
could make it clearer in the intro that 2 TLVs are defined each of which with a 
precise scope, that would make things easier.

Also the list of the PSTs is a bit confusing. Since each PST is a byte field 
why don’t you adopt and encoding like the one used in RFC7138 section 4.1.1. 
for the muxing stages? You could encode the PST values like the Stage#1…Stage# 
below.


   0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type = 1 (Unres-fix)   | Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  | Num of stages |T|S| TSG | Res |Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Stage#1|  ...  |   Stage#N |Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 0| . |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 7| Unreserved Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: Bandwidth Sub-TLV -- Type 1





Major Issues:

No major issues found.



Minor Issues:

  *   Section 3: definition of the Length field is missing. Further reading the 
document I found it later in section 3. Ordering the definitions of the fields 
accordingly with the order they appear in the TLV improves the readability.
  *   Section 3: why is the PST length needed? Why is not enough to use the 
Length field of the PSTCapability TLV?
  *   Section 3: “This document defines the following PST value:

  o  PST = 0: Path is setup using the RSVP-TE signaling protocol.” 
…please see general comment above.





Nits:

  *   Abstract: I’d suggest substituting “Traffic Engineering paths (TE paths)” 
with Traffic Engineering (TE) paths.
  *   Requirement language: usually this section is a subsection in the body of 
the draft, not in the abstract. It could be put as 1.1?
  *   Section1: “by sending the ERO and characteristics of the LSP”…shouldn’t a 
“THE” be used between “and” and “characteristics”?



Thanks

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

Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

[Daniele Ceccarelli]

On everything 

From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: lunedì 13 novembre 2017 16:41
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>; pce@ietf.org
Subject: RE: draft-ietf-pce-association-diversity: relaxing constraint

Hi Daniele,

Thanks for your feedback.
If we go to a generic mechanism, IMO, this should be addressed in a separate 
document. In addition, we need a generic way for a PCC to tell the PCE that a 
constraint is relaxable or strict. For diversity, we have a dedicated flag 
within the DISJOINTNESS TLV for that purpose. Maybe we should make it generic 
as well.

Do you agree ?

Brgds,


From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
Sent: Monday, November 13, 2017 16:33
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: draft-ietf-pce-association-diversity: relaxing constraint

Hi Stephane,

definitely needed.
My opinion is that a way to say that a constraint was relaxed is very useful. 
As you said there are different types of constraints that can be relaxed, e.g. 
diversity or a TE bound.
I would make the TLV as generic as possible and maybe define multiple sub-TLV 
(or maybe just multiple values) depending on the constraint that was relaxed.

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: lunedì 13 novembre 2017 16:22
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hi WG,

In the latest version of draft-ietf-pce-association-diversity we added a new 
TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCUpdate 
message when the PCE relaxes the requested disjointness constraint. For 
instance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, 
it may relax the constraint (if PCC allows it to do so) and thus informs the 
PCC through the RELAXED-CONSTRAINT-TLV.

IMO, this kind of behavior is more generic rather tied to the disjointness use 
case. It may be used with other constraints as well.

The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the 
association-diversity draft ? or do we drop it ? or do we define a TLV more 
specific to the association diversity state ? maybe we can reuse the 
association group object in the PCUpdate message including the 
DISJOINTNESS-INFORMATION-TLV which reflects the actual disjointness style used 
by the PCE.

Opinions ?


Brgds,

Stephane


[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
  NEW !
mobile: +33 6 71 63 27 50 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
  NEW !
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>


_



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.

_



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 d

Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

[Daniele Ceccarelli]

Hi Stephane,

definitely needed.
My opinion is that a way to say that a constraint was relaxed is very useful. 
As you said there are different types of constraints that can be relaxed, e.g. 
diversity or a TE bound.
I would make the TLV as generic as possible and maybe define multiple sub-TLV 
(or maybe just multiple values) depending on the constraint that was relaxed.

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: lunedì 13 novembre 2017 16:22
To: pce@ietf.org
Subject: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hi WG,

In the latest version of draft-ietf-pce-association-diversity we added a new 
TLV called RELAXED-CONSTRAINT-TLV to be used in LSP Object of a PCUpdate 
message when the PCE relaxes the requested disjointness constraint. For 
instance, if a PCC requests an SRLG disjoint path but the PCE cannot find it, 
it may relax the constraint (if PCC allows it to do so) and thus informs the 
PCC through the RELAXED-CONSTRAINT-TLV.

IMO, this kind of behavior is more generic rather tied to the disjointness use 
case. It may be used with other constraints as well.

The question is: do we need to keep this RELAXED-CONSTRAINT-TLV in the 
association-diversity draft ? or do we drop it ? or do we define a TLV more 
specific to the association diversity state ? maybe we can reuse the 
association group object in the PCUpdate message including the 
DISJOINTNESS-INFORMATION-TLV which reflects the actual disjointness style used 
by the PCE.

Opinions ?


Brgds,

Stephane


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

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

[Pce] draft-lazzeri-pce-residual-bw - follow up

[Daniele Ceccarelli]

Dear WG,



Just a follow up on the comments made against the residual bw draft:

(see minutes)



 
3.1<https://tools.ietf.org/wg/pce/minutes?item=minutes-99-pce-00.html#section-3.1>.
 PCEP Extensions for Residual Bandwidth (Daniele Ceccarelli, 10 min)

  [45/120] 
draft-lazzeri-pce-residual-bw<http://tools.ietf.org/html?draft=draft-lazzeri-pce-residual-bw>



  Jon: Clarification question for Daniele - Is this applicable for only 
one

   source requesting the LSP, so that reporting residual BW can be 
used?

   What happens if multiple PCCs are setting up LSPs and consuming

   resources

   separately?

  Daniele Ceccarelli: We had considered single source (a single H-PCE),

  and in

  case of multiple, some synchronization between

  them. Scope

  was a single source.

  Dhruv: Even if only single source node, the proposed mechanism will

  only work

 if there is no other path computation requests asking for

 the same

 resource. It is possible there should be a timing issue,

 i.e., the

 residual resource should only be valid for a duration of 
time.

 Shouldn't this be similar to delay metric, the delay at the

 time of

 path computation in a stateless PCRep message and receiving

 delay

 later via telemetry.

  Daniele: In the worst case, you cannot get any advantage, but it

  improves if

   you are lucky.

  Dhruv: Agree.

We were thinking of addressing the "race condition" issue as follows:

  *   Apply the concept only to stateful requests
  *   Define a flag in the path computation request that allows registering for 
residual bandwidth updates (PCEP report). IN this way if the residual bw 
changes due to LSP setup (either by other HPCE or by any other mean) the H-PCE 
can receive a notification.
Please note:

  1.  This is applicable to black topologies
  2.  This is applicable also to white topologies in those cases where 
TE-topology updates do not include path level residual bw.
  3.  It is still possible to have a number of stateless path computation 
requests (used to e.g. define the domain sequence in multi-domain scenarios) 
but then register for updates only when a stateful request is issued.

Thanks a lot
Daniele + co-authors

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

Re: [Pce] PCEP as an SDN controller protocol?

[Daniele Ceccarelli]

HI Julien,

your correction is…correct 

You’re referring to the protocols running on the DCN, or more appropriately on 
the MCN, right? The IGP is usually non TE and just providing reachability 
info…but as PCEP can be modified for other purposes, they can be modified as 
well. On this I agree with you.

Cheers
Daniele

From: Julien Meuric [mailto:julien.meu...@orange.com]
Sent: martedì 25 luglio 2017 11:36
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>; pce@ietf.org
Cc: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce-cha...@ietf.org
Subject: Re: PCEP as an SDN controller protocol?

Hi Daniele,

[Operator hat on.]

I agree on several things you wrote, starting from the answer to Jon's 
rhetorical question, which cares more about how much (at least I've never 
noticed my co-chair has a short memory).

Nevertheless the sentence below needs to be corrected, because it happens to be 
wrong: "optical networks with no control plane" is as inaccurate as "a fuel car 
with no battery".
Not relying on the high-end version of this mean to realize the core task of an 
equipment must not hide that most (even those Sonet/SDH ADMs) of the deployed 
optical devices do (mostly for management traffic, whose fate PCEP may 
share)...:
- perform IP forwarding,
- have a routing table,
- run an IGP to populate that routing table,
- run an IGP to advertise their attached addresses,
- support a large set of (IP-based) protocols for various purposes (e.g., ICMP, 
DHCP, SSH, SMTP), i.e. squeezing many roles within a single protocol is a 
non-goal.

A possible rephrasing could be "networks where the control plane is limited to 
background tasks", which reminds that operators deploy "fully packaged cars", 
not just "raw wheels with a motor" according to the misleading scope assumed in 
the current discussion.

Thanks,

Julien

Jul. 24, 2017 - 
daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>:
· It could be the SBI solution for those networks where there is no 
control plane (e.g. many NMS driven optical networks)

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

Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

[Daniele Ceccarelli]

+1

I know you don’t like +1 that much, but there isn’t that much to add. In 
Italian we’d say “salva capra e cavoli” (it saves goat and cabbage)…meaning 
it’s backward compatible and not ugly 

Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: lunedì 24 luglio 2017 10:15
To: adr...@olddog.co.uk; pce@ietf.org; draft-ietf-pce-lsp-setup-t...@ietf.org; 
draft-ietf-pce-segment-rout...@ietf.org
Cc: pce-cha...@ietf.org
Subject: Re: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?

Adrian,

The SR-PCE-CAPABILITY TLV is more than just a Boolean value - it also contains 
information about the maximum SID depth.  However, I like your idea and I think 
that it gives us a better way to do this without breaking backwards 
compatibility with existing SR implementations.

Suppose we introduce a setup-type TLV into the OPEN object as you propose, and 
assign a bit to each setup type.
If the TLV is absent, then RSVP-TE is supported.
If the TLV is absent and the SR-PCE-CAPABILITY TLV is present, then RSVP-TE and 
SR are supported.  This retains backwards compatibility with existing SR 
implementations.
If the TLV is present, then the bits indicate which setup types are supported.

We would modify the LSP setup type draft to say that implementations supporting 
path setup types other than RSVP-TE SHOULD include the setup-type TLV.

It’s not exactly beautiful, but it’s not as ugly as RSVP-TE-NON-SUPPORT.

Cheers
Jon


From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: 21 July 2017 19:55
To: Jonathan Hardwick 
>; 
pce@ietf.org; 
draft-ietf-pce-lsp-setup-t...@ietf.org;
 
draft-ietf-pce-segment-rout...@ietf.org
Cc: pce-cha...@ietf.org
Subject: RE: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?

Well, personally, if I was designing this, I would not a whole TLV for each bit 
flag!
I would have a Setup-Type TLV.
If that TLV is absent, RSVP-TE is supported.
If the TLV is present, each bit means that a different setup type is supported.

That means...
Legacy nodes don't include the TLV and are assumed to support RSVP-TE
Legacy nodes that receive the TLV don't know what it means and so object to the 
Open (leaving a new node to re-Open for RSVP-TE only).
New nodes include the TLV and so indicate explicitly what they support.

I know it is late for that type of change, so how we proceed might depend on 
what implementations have done already.

Adrian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 21 July 2017 16:07
To: pce@ietf.org; 
draft-ietf-pce-lsp-setup-t...@ietf.org;
 
draft-ietf-pce-segment-rout...@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?

Dear PCE-ers

I don’t want to distract from the SDN topic too much, but we have an important 
decision to make about draft-ietf-pce-lsp-setup-type.

The shepherd review raised an issue that there is no way for a PCEP speaker to 
indicate that it can’t (or won’t) support RSVP-TE as a path setup type.  It is 
entirely plausible that a node might not support RSVP-TE, or else have it 
disabled, for example in an SR-only network.

We think that draft-ietf-pce-lsp-setup-type should be changed to allow a 
speaker to declare that they do or don’t have support for RSVP-TE paths.  There 
are two proposals.


1.  Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a 
(new) RSVP-TE-CAPABILITY TLV in their OPEN object.  If this TLV if missing, but 
some other CAPABILITY TLV is present (such as SR-CAPABILITY) then it means that 
the speaker does not support RSVP-TE as a path setup type.

2.  Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a 
(new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON’T support 
RSVP-TE.  If this TLV is omitted, it will be assumed that they do support 
RSVP-TE.

The problem with (1) is that it is not backwards compatible.  Any existing SR 
implementation which also supports RSVP will not currently send this new 
capability.  So, if we make change (1) then forwards-level implementations will 
incorrectly conclude that such backwards-level implementations do not support 
RSVP-TE.

The problem with (2) is that it is ugly, and in my opinion we should only do 
something ugly with a new protocol extension if we simply can’t avoid doing it.

And so the question: are there any *deployments* of PCEP in a mixed SR/RSVP-TE 
environment that would be broken if we made change (1)?

Thanks
Jon

___
Pce mailing 

Re: [Pce] PCEP as an SDN controller protocol?

[Daniele Ceccarelli]

Thanks Jon for starting this discussion.

I agree with Stephane when saying that the decision to turn PCEP into an SDN 
protocol was already taken a while ago (with the active PCE IMHO).

What are the pros and cons of this approach, let me share some loud thinking:


  *   It could be the SBI solution for those networks where there is no control 
plane (e.g. many NMS driven optical networks)
  *   It could be a good alternative to Netconf/Restconf as a protocol between 
sdn controllers (sort of NBI). It's less configuration driven and more event 
oriented. It also has different reaction time.
  *   On the other side the market seems to be asking more for Netconf/Restconf 
as the single protocol between SDN controller. We should try to understand if 
this is driven by the need for a single protocol doing everything, by the lack 
of knowledge (of PCEP as a potential SDN protocol), or other reasons.
  *   It could succeed where open flow failed, being the protocol that operates 
an heterogeneous network (where there is no control plane interoperability and 
provided that readiness is done a priori via NMS).
  *   Should we adopt it just for some of the functionalities Jon listed or 
all? Well, for some of them maybe it's not worth it?...

All in all I would say I'm leaning towards a yes (to the question in the 
subject).

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: lunedì 24 luglio 2017 14:03
To: Jonathan Hardwick ; pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Hi,

As soon as we started with the active stateful PCE, the PCE became an SDN 
controller who takes decision and programs the network.
So as many already mentioned, PCEP as an SBI is already done.

IMO, PCECC does not change significantly PCEP, it's just bring a new kind of 
LSP style for this hop by hop path programming. A controller implementing hop 
by hop path programming will require more intelligence as it needs to program 
nodes in the right order to prevent transient loops...

The question is more what is the exact scope of PCEP in term of SBI and do we 
want to create a protocol that does everything , including coffee :) ?
We already have plenty of protocols: BGP, IGP, Netconf. Each protocol has 
strength and weaknesses and I'm not sure that we need to mimic all features in 
all protocols. What is the gain here ?
The best approach may be to use strength of protocols and use them for what 
they are good for:
Example:
IGP has good flooding capability with "limited scale": interesting when all 
receivers need the same information
BGP has good flooding capability with large scale and ability to target 
specific groups (using route targets/communities) : interesting when groups of 
receivers need the same information
Netconf more generic and point to point
...


IMO:
do we need PCEP-LS ? => This can be discussed, we already have two protocols to 
exchange the topology...
do we need to add configuration capabilities in PCEP => not sure, we have 
Netconf for that.
Why not limiting PCEP to path programming and path policies (traffic steering 
on path...) ?

Brgds,

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, July 20, 2017 17:22
To: pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] PCEP as an SDN controller protocol?

Dear PCE WG

The purpose of this email is to initiate a discussion about whether we want to 
extend PCEP to allow it to replace the functions that are traditionally 
provided by the routing and signalling protocols.

Originally, PCEP was designed with the goal of providing a distributed path 
computation service.  In recent years we have extended that mission, and added 
path modification and path instantiation capabilities to PCEP.  This has added 
capabilities to PCEP that would traditionally have been performed by the 
network management plane.

We are now starting to discuss proposals to add more capabilities to PCEP - 
capabilities that are traditionally part of routing and signalling.  There were 
three examples of this in the PCE working group meeting this week.

*The PCECC proposal, which extends PCEP's path instantiation capability 
so that the PCE can provision a path end-to-end by touching each hop along the 
path.  This replaces the function already provided by RSVP-TE.

*The PCEP-LS proposal, which extends PCEP to allow link state and TE 
information to be communicated from the network to the PCE.  This replaces the 
link state flooding function provided by the IGPs, or BGP-LS.

*The PCECC-SR proposal extends PCEP to allow device-level configuration 
to be communicated between the network and the PCE, such as SRGBs, prefix SIDs 
etc.  Again, this replaces functions that are already designed into the IGPs.

These proposals are taking PCEP in the direction of being a 

Re: [Pce] Poll for adoption: draft-zhuang-pce-stateful-pce-lsp-scheduling-05

[Daniele Ceccarelli]

Agree with Adrian, i support the adoption of the document.

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: venerdì 16 giugno 2017 18:18
To: 'Jonathan Hardwick' ; pce@ietf.org
Cc: draft-zhuang-pce-stateful-pce-lsp-schedul...@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] Poll for adoption: 
draft-zhuang-pce-stateful-pce-lsp-scheduling-05

Excellent news, Jon.

Really good that the authors of the two individual I-Ds were able to converge 
with a true merger (not just piling all the text together).

Really nice to see solutions work in support of 
draft-ietf-teas-scheduled-resources which is sitting in TEAS ready for last 
call but pending exactly this work.

So, yes, please adopt as a good starting point for your work.

Thanks,
Adrian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 16 June 2017 16:51
To: pce@ietf.org
Cc: 
draft-zhuang-pce-stateful-pce-lsp-schedul...@ietf.org;
 pce-cha...@ietf.org
Subject: [Pce] Poll for adoption: 
draft-zhuang-pce-stateful-pce-lsp-scheduling-05

All,

This is the start of a two week poll on making 
draft-zhuang-pce-stateful-pce-lsp-scheduling-05 a PCE working group document.
https://datatracker.ietf.org/doc/draft-zhuang-pce-stateful-pce-lsp-scheduling/


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 Friday, June 30.



Many thanks,
Jon


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

Re: [Pce] New Version Notification for draft-lazzeri-pce-residual-bw-00.txt

[Daniele Ceccarelli]

Hi WG,

We just uploaded a new draft defining the extensions to PCEP for the usage of 
the Path Residual Bandwdith.
Please see the abstract below.

Thanks
Francesco, Young, Daniele  

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: venerdì 12 maggio 2017 17:26
To: Francesco Lazzeri <francesco.lazz...@ericsson.com>; Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com>; Young Lee <leeyo...@huawei.com>
Subject: New Version Notification for draft-lazzeri-pce-residual-bw-00.txt


A new version of I-D, draft-lazzeri-pce-residual-bw-00.txt
has been successfully submitted by Daniele Ceccarelli and posted to the IETF 
repository.

Name:   draft-lazzeri-pce-residual-bw
Revision:   00
Title:  Extensions to the Path Computation Element Protocol (PCEP) for 
residual path bandwidth support
Document date:  2017-05-12
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-lazzeri-pce-residual-bw-00.txt
Status: https://datatracker.ietf.org/doc/draft-lazzeri-pce-residual-bw/
Htmlized:   https://tools.ietf.org/html/draft-lazzeri-pce-residual-bw-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-lazzeri-pce-residual-bw-00


Abstract:
 The ability of a hierarchy of PCEs to compute accurate end-to-end
   paths across multiple domains is recognized as an important
   requirement in many applications.
  This document describes extensions to the PCE Communication
   Protocol (PCEP) in order to provide new path-related bandwidth
   metrics, which a PCC, like a H-PCE (either stateful or stateless),
   can use from an erstwhile path computation to deploy multiple LSPs
   (having the same end-points and constraints) without additional
   requests, until either the remaining bandwidth along that path is
   all allocated or a deployment fails.
  This information would also be beneficial for implementing
   abstractions of the domain topology, building the abstract
   connectivity incrementally, based only on really used constraints,
   as soon as path computation results are returned.


  


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.

The IETF Secretariat

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

Re: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

[Daniele Ceccarelli]

Yes/support

Daniele


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, January 05, 2017 9:24 AM
To: pce@ietf.org
Cc: 
draft-dhody-pce-stateful-pce-auto-bandwi...@ietf.org;
 pce-cha...@ietf.org
Subject: [Pce] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09


All,



This is start of a two week poll on making 
draft-dhody-pce-stateful-pce-auto-bandwidth-09 a PCE working group document.

https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-auto-bandwidth/



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 Thursday January 19.



Thanks,

Jon, JP and Julien

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

[Pce] draft-ietf-pce-wson-rwa-ext-05 - Shepherd review

[Daniele Ceccarelli]

Dear authors, WG,

i carried the shepherd review of this document, please find below some comments 
and issues that should be fixed as part of the WG last call.

BR
Daniele


-  ID nits:  Summary: 14 errors (**), 0 flaws (~~), 17 warnings 
(==), 2 comments (--). Please note that there is a number of too long lines in 
the document and that the references need to be fixed (missing references, 
unused references, downref and outdated reference.

-  Intended Status (front page): it should be Standard Track

-  Front page: Ramon's affiliation is not properly formatted

-  Section 3: suggested change for improved readability

o   OLD

In this document, it is assumed that wavelength converters require

   electrical signal regeneration. Consequently, WSONs can be

   transparent (A transparent optical network is made up of optical

   devices that can switch but not convert from one wavelength to

   another, all within the optical domain) or translucent (3R

   regenerators are sparsely placed in the network).

o   NEW

WSONs can be transparent or translucent. A transparent optical

network is made up of optical devices that can switch but not convert

from one wavelength to another, all within the optical domain. On the

other side translucent networks include 3R regenerators sparsely placed.

In this document only wavelength converters that require electrical signal

regeneration are considered.

-  Section 3: Expand LSC at first use

-  Section 3: s/need not operate/do not need to operate

-  Section 3:

o   OLD

   Two optical paths that share a common fiber link cannot be assigned

   the same wavelength.  To do otherwise would result in both signals

   interfering with each other

o   NEW

   Two optical paths that share a common fiber link cannot be assigned

   the same wavelength otherwise both signals would interfere with each other

-  Section 3 - Figure 1: what do X and LSC stand for in the figure? 
Reading further it says: "If the LSC LSP induced a Forwarding Adjacency / TE 
link, the switching capabilities of the TE link would be [X X] where X < LSC 
(PSC, TDM, ...)" but it is not yet clear what it means.

-  Section 3: s/wavelength MUST be/wavelength must be

-  Section 4.1

o   OLD

   (a) By means of Explicit Label Control (ELC) where the PCE allocates

   which label to use for each interface/node along the path. in the

   sense that the allocated labels MAY appear after an interface route

   subobject.

o   NEW

   (a) By means of Explicit Label Control (ELC), where the PCE allocates

the label to be use on each interface/node along the path. In this case

  that the allocated labels may appear after an interface route sub-object.

-  Figure 3: 31 bits reserved for flags and only 1 used is a 
significant waste. Suggestion: whi don't you split the field into 16 reserved 
and 16 flags?

-  Section 4.2: Drop "to ''explicit'' and could add "The Walelngth 
Selection TLV MUST NOT be used when the M bit is cleared"

-  Section 4.4 s/ include/includes

-  Section 4.4 drop "however this is not a MUST".

-  Section 4.4.1: What is the X field at the beginning of the object? 
Type = X seems to be referring to that. Moreover indication of how to encode 
the "length" field is missing.

-  Section 4.4.1 :Attribute: if it can only assume 2 values why using 8 
bits? If other future values can be defined I'd suggest to rephrase saying 
something like: "actually the following 2 values are defined".

-  Figure 6: maybe you should add Type and Length? This TLV is encoded, 
ulikely the analogous WA object, using Reserved instead of flags.

-  Section 5:  the text says that link identifier and assigned 
wavelength fields have variable length, the figure should be updated 
accordingly.

-  Section 5.2: s/One new bit flag are/One new flag is

-  Section 6.2: is it still needed?


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

Re: [Pce] [Teas] [mpls] IETF 97 - Minutes

[Daniele Ceccarelli]

Hi Xufeng,

Thanks for the note. Minutes fixed.

https://www.ietf.org/proceedings/97/minutes/minutes-97-ccamp-01.htm

BR
Daniele

From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Xufeng Liu
Sent: martedì 29 novembre 2016 22:56
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>; 'CCAMP' 
<cc...@ietf.org>
Cc: m...@ietf.org; pce@ietf.org; 'TEAS WG' <t...@ietf.org>
Subject: Re: [Teas] [mpls] IETF 97 - Minutes

Hi Daniele, Fatiai and Oscar,

For item 4, It will be good to add a record saying that we planned to split 
draft-ietf-mpls-ldp-mldp-yang-00 into two documents: draft-ietf-mpls-ldp-yang 
and draft-ietf-mpls-mldp-yang, as presented during the session. This is not 
obvious when looking at the linked presentation draft. The split documents were 
submitted right after the presentation.

Thanks,

- Xufeng

From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: Monday, November 28, 2016 8:53 AM
To: CCAMP (cc...@ietf.org<mailto:cc...@ietf.org>) 
<cc...@ietf.org<mailto:cc...@ietf.org>>
Cc: m...@ietf.org<mailto:m...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>; 
TEAS WG (t...@ietf.org<mailto:t...@ietf.org>) 
<t...@ietf.org<mailto:t...@ietf.org>>
Subject: [mpls] IETF 97 - Minutes

Hi all,

the first draft of the CCAMP and joint YANG session minutes is now available at 
the following link: 
https://www.ietf.org/proceedings/97/minutes/minutes-97-ccamp-00.htm

Thanks a lot to Italo, Haomian and Yoji for the help with notes taking.

Thanks
Daniele, Fatai, Oscar
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy

[Daniele Ceccarelli]

Support,

BR
Daniele  

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Leeyoung
> Sent: venerdì 25 novembre 2016 12:59
> To: Julien Meuric 
> Cc: pce@ietf.org
> Subject: Re: [Pce] Poll for Adoption of draft-dhody-pce-association-policy
> 
> Support,
> 
> Young
> 
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> Sent: Thursday, November 24, 2016 10:04 AM
> To: pce@ietf.org
> Subject: [Pce] Poll for Adoption of draft-dhody-pce-association-policy
> 
> Hi all,
> 
> Though it is a -00, draft-dhody-pce-association-policy already has a long
> history: thanks to the authors for the common work. During our meeting in
> Seoul, it received some support from the room. We now want to know
> whether the list agrees to adopt it as a foundation for a PCE WG document.
> Please, share your comments on the mailing list.
> 
> Regards,
> 
> Julien
> 
> ___
> 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

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

[Pce] IETF 97 - Minutes

[Daniele Ceccarelli]

Hi all,

the first draft of the CCAMP and joint YANG session minutes is now available at 
the following link: 
https://www.ietf.org/proceedings/97/minutes/minutes-97-ccamp-00.htm

Thanks a lot to Italo, Haomian and Yoji for the help with notes taking.

Thanks
Daniele, Fatai, Oscar
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Slides for Joint YANG session

[Daniele Ceccarelli]

The joint YANG session will be on Monday and as of Sunday afternoon 8 slide 
decks out of 12 are still missing !!

If you sent the slides and you don't see them in the meeting material 
(sorry...) please send a ping, otherwise please have them sent ASAP.
Oscar is not here at this time, please remember to send them also to Fatai and 
myself.

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

Re: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

[Daniele Ceccarelli]

Makes sense.

Cheers
Daniele

From: Igor Bryskin [mailto:igor.brys...@huawei.com]
Sent: giovedì 3 novembre 2016 15:35
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>; Scharf, Michael 
(Nokia - DE) <michael.sch...@nokia.com>; CCAMP (cc...@ietf.org) 
<cc...@ietf.org>; pce@ietf.org; TEAS WG (t...@ietf.org) <t...@ietf.org>; 
m...@ietf.org
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

For the client to keep returned by the provider path state means requesting 
from the provider periodic path re-computations.  Provider can re-evaluate 
previously returned path in an event driven way (e.g. reacting on TED change 
affecting one of the path's links).

From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
Sent: Thursday, November 03, 2016 10:19 AM
To: Igor Bryskin; Scharf, Michael (Nokia - DE); CCAMP 
(cc...@ietf.org<mailto:cc...@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; 
TEAS WG (t...@ietf.org<mailto:t...@ietf.org>); 
m...@ietf.org<mailto:m...@ietf.org>
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi Igor,

Understood the concept. It is clear but I'm still struggling with its 
usefulness. What you call statefull and stateless is with respect to the domain 
controller, but I see the statefullness and stateless of the paths an higher 
level controller issue and fair enough to have the stateless concept in the 
domain controller.
In other words if the higer level controller wants to keep the state of the 
path why doesn't it simply do that instead of demanding it to the domain 
controller? Because if should be made available also to someone else?

Cheers
Daniele


From: Igor Bryskin [mailto:igor.brys...@huawei.com]
Sent: giovedì 3 novembre 2016 15:04
To: Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>>; 
Scharf, Michael (Nokia - DE) 
<michael.sch...@nokia.com<mailto:michael.sch...@nokia.com>>; CCAMP 
(cc...@ietf.org<mailto:cc...@ietf.org>) 
<cc...@ietf.org<mailto:cc...@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>; 
TEAS WG (t...@ietf.org<mailto:t...@ietf.org>) 
<t...@ietf.org<mailto:t...@ietf.org>>; m...@ietf.org<mailto:m...@ietf.org>
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

HI Daniele,

A client may ask for a path not to be used immediately (e.g. to present as an 
abstract link to its own client, in some failure restoration scheme or as a 
part of disaster recovery network topology re-configuration). In this case the 
client would want to know at least  if/when the path has stopped being feasible 
any longer or (ideally) a better path is available.

Igor

From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP 
(cc...@ietf.org<mailto:cc...@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; 
TEAS WG (t...@ietf.org<mailto:t...@ietf.org>); 
m...@ietf.org<mailto:m...@ietf.org>
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Can you please explain what the "stateful compute-only" stands for I don't 
understand what is stateful in a path computation request only.
IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path and 
then forget about it or I ask to compute and provision it. I don't understand 
the value of asking for it and remembering about it.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:michael.sch...@nokia.com]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <igor.brys...@huawei.com<mailto:igor.brys...@huawei.com>>; 
Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>>; 
CCAMP (cc...@ietf.org<mailto:cc...@ietf.org>) 
<cc...@ietf.org<mailto:cc...@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>; 
TEAS WG (t...@ietf.org<mailto:t...@ietf.org>) 
<t...@ietf.org<mailto:t...@ietf.org>>; m...@ietf.org<mailto:m...@ietf.org>
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

We have discussed this before. From an implementer's perspective, the two clean 
solutions to the problem seem to either stateful "compute-only" tunnels or a 
stateless RPC.

Michael


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cc...@ietf.org<mailto:cc...@ietf.org>); 
pce@ietf.org<mailto:pce@ietf.org>; TEAS WG 
(t...@ietf.org<mailto:t...@ietf.org>); m...@ietf.org<mailto:m...@ietf.org>
Subject: [ALU] 
[mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi,

>From the draft:

6.YANG Model for requesting Path Compu

Re: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

[Daniele Ceccarelli]

Hi Igor,

Understood the concept. It is clear but I'm still struggling with its 
usefulness. What you call statefull and stateless is with respect to the domain 
controller, but I see the statefullness and stateless of the paths an higher 
level controller issue and fair enough to have the stateless concept in the 
domain controller.
In other words if the higer level controller wants to keep the state of the 
path why doesn't it simply do that instead of demanding it to the domain 
controller? Because if should be made available also to someone else?

Cheers
Daniele


From: Igor Bryskin [mailto:igor.brys...@huawei.com]
Sent: giovedì 3 novembre 2016 15:04
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>; Scharf, Michael 
(Nokia - DE) <michael.sch...@nokia.com>; CCAMP (cc...@ietf.org) 
<cc...@ietf.org>; pce@ietf.org; TEAS WG (t...@ietf.org) <t...@ietf.org>; 
m...@ietf.org
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

HI Daniele,

A client may ask for a path not to be used immediately (e.g. to present as an 
abstract link to its own client, in some failure restoration scheme or as a 
part of disaster recovery network topology re-configuration). In this case the 
client would want to know at least  if/when the path has stopped being feasible 
any longer or (ideally) a better path is available.

Igor

From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
Sent: Thursday, November 03, 2016 9:49 AM
To: Scharf, Michael (Nokia - DE); Igor Bryskin; CCAMP 
(cc...@ietf.org<mailto:cc...@ietf.org>); pce@ietf.org<mailto:pce@ietf.org>; 
TEAS WG (t...@ietf.org<mailto:t...@ietf.org>); 
m...@ietf.org<mailto:m...@ietf.org>
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Can you please explain what the "stateful compute-only" stands for I don't 
understand what is stateful in a path computation request only.
IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path and 
then forget about it or I ask to compute and provision it. I don't understand 
the value of asking for it and remembering about it.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:michael.sch...@nokia.com]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <igor.brys...@huawei.com<mailto:igor.brys...@huawei.com>>; 
Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>>; 
CCAMP (cc...@ietf.org<mailto:cc...@ietf.org>) 
<cc...@ietf.org<mailto:cc...@ietf.org>>; pce@ietf.org<mailto:pce@ietf.org>; 
TEAS WG (t...@ietf.org<mailto:t...@ietf.org>) 
<t...@ietf.org<mailto:t...@ietf.org>>; m...@ietf.org<mailto:m...@ietf.org>
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

We have discussed this before. From an implementer's perspective, the two clean 
solutions to the problem seem to either stateful "compute-only" tunnels or a 
stateless RPC.

Michael


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cc...@ietf.org<mailto:cc...@ietf.org>); 
pce@ietf.org<mailto:pce@ietf.org>; TEAS WG 
(t...@ietf.org<mailto:t...@ietf.org>); m...@ietf.org<mailto:m...@ietf.org>
Subject: [ALU] 
[mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi,

>From the draft:

6.YANG Model for requesting Path Computation


   Work on extending the TE Tunnel YANG model to support the need to
   request path computation has recently started also in the context of
   the 
[TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>]
 draft.

   It is possible to request path computation by configuring a
   "compute-only" TE tunnel and retrieving the computed path(s) in the
   LSP(s) Record-Route Object (RRO) list as described in 
[TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>].

   This is a stateful solution since the state of each created
   "compute-only" TE tunnel needs to be maintained and updated, when
   underlying network conditions change.

   The need also for a stateless solution, based on an RPC, has been
   recognized.


   The YANG model to support stateless RPC is for further study.





IB>> Please, note, that in the TE Tunnel model we consider the 
COMPUTE_AND_FORGET mode. We also consider the concept of path computation 
action to be defined under the TE tunnel node. All this is to facilitate 
stateless path computations.

Cheers,
Igor

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

Re: [Pce] http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

[Daniele Ceccarelli]

Can you please explain what the "stateful compute-only" stands for I don't 
understand what is stateful in a path computation request only.
IMHO either I ask the PCE (SDN controller, NMS, whatever) to compute a path and 
then forget about it or I ask to compute and provision it. I don't understand 
the value of asking for it and remembering about it.

BR
Daniele

From: Scharf, Michael (Nokia - DE) [mailto:michael.sch...@nokia.com]
Sent: giovedì 3 novembre 2016 14:45
To: Igor Bryskin <igor.brys...@huawei.com>; Daniele Ceccarelli 
<daniele.ceccare...@ericsson.com>; CCAMP (cc...@ietf.org) <cc...@ietf.org>; 
pce@ietf.org; TEAS WG (t...@ietf.org) <t...@ietf.org>; m...@ietf.org
Subject: RE: 
http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

We have discussed this before. From an implementer's perspective, the two clean 
solutions to the problem seem to either stateful "compute-only" tunnels or a 
stateless RPC.

Michael


From: mpls [mailto:mpls-boun...@ietf.org] On Behalf Of Igor Bryskin
Sent: Thursday, November 03, 2016 2:34 PM
To: Daniele Ceccarelli; CCAMP (cc...@ietf.org<mailto:cc...@ietf.org>); 
pce@ietf.org<mailto:pce@ietf.org>; TEAS WG 
(t...@ietf.org<mailto:t...@ietf.org>); m...@ietf.org<mailto:m...@ietf.org>
Subject: [ALU] 
[mpls]http://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00

Hi,

>From the draft:

6.YANG Model for requesting Path Computation


   Work on extending the TE Tunnel YANG model to support the need to
   request path computation has recently started also in the context of
   the 
[TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>]
 draft.

   It is possible to request path computation by configuring a
   "compute-only" TE tunnel and retrieving the computed path(s) in the
   LSP(s) Record-Route Object (RRO) list as described in 
[TE-TUNNEL<https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00#ref-TE-TUNNEL>].

   This is a stateful solution since the state of each created
   "compute-only" TE tunnel needs to be maintained and updated, when
   underlying network conditions change.

   The need also for a stateless solution, based on an RPC, has been
   recognized.


   The YANG model to support stateless RPC is for further study.





IB>> Please, note, that in the TE Tunnel model we consider the 
COMPUTE_AND_FORGET mode. We also consider the concept of path computation 
action to be defined under the TE tunnel node. All this is to facilitate 
stateless path computations.

Cheers,
Igor

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

[Pce] CCAMP and JOINT YANG session agenda @IETF97

[Daniele Ceccarelli]

Hi all,

the first version of the agenda for the CCAMP session and the Joint YANG 
session is available at the following link.

https://www.ietf.org/proceedings/97/agenda/agenda-97-ccamp-01

Please let us have your comments

Thanks
MPLS, PCE, TEAS and CCAMP (chairs and secretaries)
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IETF 97 - CCAMP slot request

[Daniele Ceccarelli]

Hi all,

A friendly reminder. Please note that the deadline for asking a slot for the 
CCAMP session or the joint YANG session is TODAY.

Thanks
Daniele

From: CCAMP [mailto:ccamp-boun...@ietf.org] On Behalf Of Oscar González de Dios
Sent: mercoledì 19 ottobre 2016 10:48
To: CCAMP 
Subject: [CCAMP] IETF 97 - CCAMP slot request

Dear CCAMPers,

IETF 97 meeting @ Seoul is approaching and it's time to start collecting agenda 
slots requests.



Please, keep this in mind:


WG Draft authors are expected to present if there are open issues to discuss, 
or to send status to the list  *1 week* prior to the WG meeting if not 
presenting. Status includes review of: any recent changes, any open discussions 
or issues, and planned next steps.



Agenda Requests:

- To submit a request, please fill the survey at the following link: 
http://www.surveygizmo.com/s3/3124554/IETF-97-CCAMP-sessions-slot-requests
- As there will be also a joint Yang session with other working groups, please 
indicate in the slot request if the authors believe that the draft should be 
presented in this joint YANG session only, in the CCAMP session only or in both.

- Please fill the survey no later than Thursday, October 27th.



Presentations:

  If you are presenting slides please make sure you send them to  all 
*individuals* listed above (Chairs, Secretary and exclude CCAMP) no later  than 
Sunday, November 13th.



Reminder about a few important dates:

* 2016-10-31 (Monday): Internet Draft submission cut-off (for all drafts, 
including -00) by UTC 23:59, upload using IETF ID Submission 
Tool.
* 2016-10-31 (Monday): Draft Working Group agendas due by UTC 23:59, upload 
using IETF Meeting Materials Management 
Tool.
* 2016-11-07 (Monday): Revised Working Group agendas due by UTC 23:59, upload 
using IETF Meeting Materials Management 
Tool.
* 2016-11-13 - 2016-11-18: IETF 97 in Seoul, South Korea

Best Regards,

Óscar

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

Re: [Pce] 答复: Poll on Adoption of draft-minei-pce-association-group-03

[Daniele Ceccarelli]

I think the document is a good starting point for WG work, hence support its 
adoption.

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Zhenghaomian
Sent: lunedì 16 novembre 2015 09:19
To: Julien Meuric
Cc: pce@ietf.org
Subject: [Pce] 答复: Poll on Adoption of draft-minei-pce-association-group-03

Yes/Support.


On 3 November 2015 at 19:36, Julien Meuric 
> wrote:
Dear all,

Following our discussion during the WG meeting yesterday, do you support the 
adoption of draft-minei-pce-association-group-03 as a starting point for a new 
PCE WG item? If not, please motivate your answer.

In any case, comments are welcome.

Regards,

Jon, JP & Julien

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

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

Re: [Pce] Initial version for liaison text: New Liaison Statement, "Achieving Packet Network Optimization using DWDM Interfaces"

[Daniele Ceccarelli]

Hi CCAMP, TEAS and PCE,

Please find below a slightly revised text for the reply to the BBF liaison. We 
took the commitment to send this by mid of this week, please let us know if you 
have any concern with the text.

“The TEAS, PCE and CCAMP working groups would like to thank you for informing 
of us of the BBF effort on packet-optical networks and sending the document to 
us for review.

Reviewing the requirements proposed in the document, we noted the reference to 
IETF RFCs on GMPLS and PCE for satisfying the control requirements. As you 
progress your work, please inform us if you identify any gaps in order to 
satisfy these requirements.

For your information, IETF CCAMP is working on an update regarding the 
management and control of DWDM optical interface parameters and GMPLS protocols 
(please refer to draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk) which might be 
relevant to your project. This draft is still an individual contribution but it 
was indicated as “candidate for WG adoption” at the last meeting. The document 
has a set of companion documents defining extensions for SNMP 
(draft-galikunze-ccamp-dwdm-if-snmp-mib), LMP 
(draft-dharinigert-ccamp-dwdm-if-lmp) and YANG data models ( 
https://tools.ietf.org/html/draft-dharini-netmod-dwdm-if-yang-00 ). These 
documents are still in the individual contribution status and will be evaluated 
for WG adoption after the framework.
Feedback from the BBF would be highly appreciated and can be provided on the 
CCAMP mailing list without the need for a formal liaison.”


Thanks
Daniele & Fatai

From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: domenica 1 novembre 2015 04:27
To: Zhenghaomian; 'cc...@ietf.org'; pce@ietf.org; TEAS WG
Subject: Re: [Teas] Initial version for liaison text //答复: CALL FOR VOLUNTEER - 
New Liaison Statement, "Achieving Packet Network Optimization using DWDM 
Interfaces"


Hi Haomian, all,



Thanks for starting putting together the reply. Please find some updated 
proposals from my side.



===

The working groups in IETF routing area would like to thank you for sending 
this liaison. We much appreciate BBF on the effort of packet over optical, and 
sending the document to IETF CCAMP, TEAS and PCE WGs for review. This project 
defines a set of control plane requirements that the Physically Separated Model 
should be satisfied. We have some questions and comments:



Questions:

· It is not clear to us how the communication between the packet layer 
and the optical layer occurs. E.g. control channels, signaling and so on.

· We would like to see some more details on the management aspects 
between the packet domain and the optical domain.

Comments:

· When referring to PCE and related issues, e.g., in [R-26] and [R-27], 
it seems only stateless PCE (RFC4655) and corresponding PCEP (RFC5520) are 
included in the current version. As IETF PCE working group is investigating on 
stateful PCE, PCE Initiation and PCE as a Central Controller, which are planned 
to be published in the future, it is better to specify which kind of PCE is now 
referred by this documents. Moreover, RFC 5623, PCE-based inter-layer MPLS and 
GMPLS Traffic Engineering, may be a good reference for this document.

· In section 4.4 when talking about SDN, Openflow is mentioned as a 
standard protocol to interact between packet nodes and DWDM nodes. We would 
like to suggest add PCE Protocol (PCEP) as another example, as it is currently 
used in IETF. Besides, it is suggest to reference to RFC 3413 about SNMP, and 
RFC 4208 about GMPLS UNI.

· In section 4.5, [R-36] is not clear whether to be applied to the 
north-bound of SDN controller, or between the packet NE and SDN controller. We 
prefer the latter one.



It seems to us the requirements proposed in the current document could be 
addressed by the referenced RFCs defined for GMPLS, so we would like to make 
sure if you have identified any gaps, which need an update on GMPLS/PCEP to 
satisfy these requirements. IETF CCAMP is discussing to define a framework for 
Management and Control of DWDM optical interface parameters and GMPLS protocols 
that need to be updated, which might be relevant to your project, but this work 
in CCAMP is still in individual drafts stage. We would like to receive your 
input.





Thanks

Daniele



> -Original Message-

> From: CCAMP [mailto:ccamp-boun...@ietf.org] On Behalf Of Zhenghaomian

> Sent: martedì 27 ottobre 2015 18:17

> To: 'cc...@ietf.org'; pce@ietf.org<mailto:pce@ietf.org>; TEAS WG

> Subject: [CCAMP] Initial version for liaison text //答复: CALL FOR

> VOLUNTEER - New Liaison Statement, "Achieving Packet Network

> Optimization using DWDM Interfaces"

>

> Hi, All,

>

> After reviewing the liaison and document from BBF, we would like to provide

> the following text as an ini

Re: [Pce] Poll on Adoption of draft-minei-pce-association-group-03

[Daniele Ceccarelli]

Hi J3P and WG,

Yes, I think the draft should be adopted as WG item.

BR
Daniele

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of wang.qi...@zte.com.cn
Sent: mercoledì 4 novembre 2015 09:44
To: Julien Meuric; pce@ietf.org
Subject: Re: [Pce] Poll on Adoption of draft-minei-pce-association-group-03

yes/support

Thanks
Qilei



Julien Meuric >
发件人:  "Pce" >

2015-11-04 08:36

收件人

"pce@ietf.org" >,

抄送

主题

[Pce] Poll on Adoption of draft-minei-pce-association-group-03







Dear all,

Following our discussion during the WG meeting yesterday, do you support
the adoption of draft-minei-pce-association-group-03 as a starting point
for a new PCE WG item? If not, please motivate your answer.

In any case, comments are welcome.

Regards,

Jon, JP & Julien

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

Re: [Pce] Initial version for liaison text //答复: CALL FOR VOLUNTEER - New Liaison Statement, "Achieving Packet Network Optimization using DWDM Interfaces"

[Daniele Ceccarelli]

 referenced RFCs defined for GMPLS, so we would like to

> make sure if you have identified any gaps, which need an update on GMPLS

> to satisfy these requirements. IETF CCAMP is discussing to define a

> framework for Management and Control of DWDM optical interface

> parameters and GMPLS protocols that need to be updated, which might be

> relevant to your project, but this work in CCAMP is still in individual drafts

> stage. We would like to receive your input.

> ==

> ========

>

> Thanks.

>

> Best wishes,

> Haomian

>

> -邮件原件-

> 发件人: Zhenghaomian

> 发送时间: 2015年10月21日 11:11

> 收件人: Daniele Ceccarelli; Fatai Zhang

> 抄送: cc...@ietf.org<mailto:cc...@ietf.org>

> 主题: 答复: CALL FOR VOLUNTEER - New Liaison Statement, "Achieving

> Packet Network Optimization using DWDM Interfaces"

>

> Daniele, Fatai and All,

>

> I would like to volunteer for generating the response liaison, as the topic is

> highly related to my research work. I will review the document and share my

> comments early next week. Please also feel free to share your opinion,

> thanks.

>

> Best wishes,

> Haomian

>

> -邮件原件-

> 发件人: CCAMP [mailto:ccamp-boun...@ietf.org] 代表 Daniele Ceccarelli

> 发送时间: 2015年10月20日 23:46

> 收件人: CCAMP (cc...@ietf.org<mailto:cc...@ietf.org>)

> 主题: [CCAMP] CALL FOR VOLUNTEER - New Liaison Statement, "Achieving

> Packet Network Optimization using DWDM Interfaces"

>

> WG,

>

> We received this liaison from BBF on Packet-Optical integration.

> I'm copying the links to liaison and attachment here for your convenience

> Liaison:  https://datatracker.ietf.org/liaison/1432/

> Attachment: 
> https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-<https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-10-16-broadband-forum-rtg-ccamp-teas-achieving-packet-network-optimization-using-dwdm-interfaces-attachment-1.pdf>

> 10-16-broadband-forum-rtg-ccamp-teas-achieving-packet-network-<https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-10-16-broadband-forum-rtg-ccamp-teas-achieving-packet-network-optimization-using-dwdm-interfaces-attachment-1.pdf>

> optimization-using-dwdm-interfaces-attachment-1.pdf<https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2015-10-16-broadband-forum-rtg-ccamp-teas-achieving-packet-network-optimization-using-dwdm-interfaces-attachment-1.pdf>

>

> We'd really like 1 or 2 volunteers interested in the topic to draft an answer 
> to

> the liaison before the meeting in Yokohama so to be able to discuss it on the

> list and reply during or immediately after the meeting.

>

> Please consider volunteering.

> Thanks

> Fatai & Daniele

>

> > -Original Message-

> > From: Liaison Statement Management Tool [mailto:l...@ietf.org]

> > Sent: venerdì 16 ottobre 2015 22:05

> > To: db3...@att.com<mailto:db3...@att.com>; 
> > vbee...@juniper.net<mailto:vbee...@juniper.net>; 
> > akat...@gmail.com<mailto:akat...@gmail.com>;

> > aret...@cisco.com<mailto:aret...@cisco.com>; 
> > lber...@labn.net<mailto:lber...@labn.net>; 
> > zhangfa...@huawei.com<mailto:zhangfa...@huawei.com>; Daniele

> > Ceccarelli

> > Cc: Alvaro Retana; Deborah Brungard; David Sinicrope; Fatai Zhang;

> > Alia Atlas; Vishnu Pavan Beeram; The IETF Chair; Daniele Ceccarelli;

> > Lou Berger; Common Control and Measurement Plane Discussion List;

> > michael.farg...@centurylink.com<mailto:michael.farg...@centurylink.com>; 
> > Traffic Engineering Architecture and

> > Signaling Discussion List

> > Subject: New Liaison Statement, "Achieving Packet Network Optimization

> > using DWDM Interfaces"

> >

> > Title: Achieving Packet Network Optimization using DWDM Interfaces

> > Submission Date: 2015-10-16 URL of the IETF Web page:

> > https://datatracker.ietf.org/liaison/1432/

> > Please reply by 2015-11-08

> > From:  (David Sinicrope 
> > <david.sinicr...@ericsson.com<mailto:david.sinicr...@ericsson.com>>)

> > To:  (vbee...@juniper.net<mailto:vbee...@juniper.net>, 
> > lber...@labn.net<mailto:lber...@labn.net>, 
> > akat...@gmail.com<mailto:akat...@gmail.com>,

> > aret...@cisco.com<mailto:aret...@cisco.com>, 
> > db3...@att.com<mailto:db3...@att.com>, 
> > daniele.ceccare...@ericsson.com<mailto:daniele.ceccare...@ericsson.com>,

> > zhangfa...@huawei.com<mailto:zhangfa...@huawei.com>)

> > Cc:

> > Response Contacts: 
> > michael.farg...@cent

Re: [Pce] [Teas] Architectural question about resource-scheduled LSPs

[Daniele Ceccarelli]

Hi Dieter,

In line.

BR
Daniele

From: Dieter Beller [mailto:dieter.bel...@alcatel-lucent.com]
Sent: venerdì 24 luglio 2015 07:47
To: Daniele Ceccarelli
Cc: adr...@olddog.co.uk; pce@ietf.org; t...@ietf.org
Subject: Re: [Teas] Architectural question about resource-scheduled LSPs

Hi Daniele,

please find my comments in-line below.

Thanks,
Dieter
On 23.07.2015 16:13, Daniele Ceccarelli wrote:

Hi Adrian,



Thanks for the excellent analysis and summary.



I think that distributing the time reservation info just to the PCC and then 
realigning the other PCEs is the best option.



Performing a realignment via IGP can cause scalability issues as you said 
(maybe BGP could be the only appropriate alternative to PCEP). Distributing the 
info to all the nodes (e.g. via RSVP) is not needed IMO, it's a burden that 
does not bring any value and is applicable only to RSVP-TE, while keeping the 
reservation on the PCC could allow for bandwidth scheduling also in other cases 
like e.g. segment routing.
did you mean OSPF and OSPF-TE, respectively? RSVP signaling may only help to 
update the DBs in the nodes along the path of an LSP. All other nodes
do not see these messages. So, the IGP has to be used to accomplish that all 
DBs are in sync.

[DanCe] no I meant RSVP-TE. One option is IGP flooding, the other one is to 
make the reservation on the nodes (via signaling) for a future time interval. 
In any case both options are not even comparable in terms of complexity and 
scalability (and openness to other control mechanisms) compared to PCEP 
notifications to all the other PCEs.



Sync between PCEs is another opportunity but then we end up in complex synch 
issues (who's the master? Who is right in case of conflict?).
Is this really a difficult problem to solve? One could imagine that the PCE 
that calculated the path starting from the head node of the LSP is always the 
master
and that this PCE instance syncs all the other PCE instances or a similar rule.
[DanCe] what if such PCE is not reachable for a while? How do the other PCEs 
know which is the master PCE for the each given LSP to be? Storing this info on 
the nodes in the most reliable solution IMHO.



 If we send the info to the PCC (i.e. the network), the network is always right 
in case of contentious and the PCEs can align with it.



Cheers,

Daniele



-Original Message-

From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Adrian Farrel

Sent: giovedì 23 luglio 2015 15:51

To: pce@ietf.orgmailto:pce@ietf.org; t...@ietf.orgmailto:t...@ietf.org

Subject: [Teas] Architectural question about resource-scheduled LSPs



Hi,



Having listened to the two presentations on scheduled LSPs in PCE and one in

TEAS I think we need to do some architectural work and make sure we are all

on the same page.



This work probably needs to be squared off across the two WGs and possibly

also MPLS.



The architectural question is Where is future scheduled resource reservation

data held?



The options are:

i. Solely in a centralised DB

ii. In several distributed DBs that might be periodically synchronised iii.

Distributed into the network iv. Some combination of the above.



In the old world, the management system held all information about

connections in the network. Such management systems were able to

schedule connection establishment as well since they had a full view of all

resources and all connections.



In MPLS/GMPLS, the pendulum swung. Connection state was held in the

network and not widely known. Only current resource availability was

distributed. In such systems, scheduled connections required a management

system that could access the current resource availability and plan the

scheduled connections. But this approach was vulnerable to connections set

up by other entities (in a distributed manner) that might steal resources

needed for a planned future connection.



One of the proposed solutions to this problem is that scheduled state is

distributed into the network by signaling. That is, an RSVP Path message

includes the timing parameters and the resources can be reserved by the

network devices for use at the specified time. The disadvantages of this

approach are that the network nodes have to have per-resource time-based

databases (which may be quite complex), and that other nodes in the

network (such as other head-end nodes, or PCEs) do not know about the

future reservations.



The answer to the second point is to report the future reservations either in

PCEP or in the IGP. Doing it in the IGP means that every node in the network

can see the future reservations, but may have an interesting scaling impact.

Doing it in PCEP means the PCE is in synch with the network, but doesn't help

other LSRs so implies a PCE-controlled scheduling system.



At this point we might ask why, if the resource scheduling is controlled by the

PCE, we need to distribute the scheduling information in the network. Why

not just leave the time

Re: [Pce] Adopting of draft-sivabalan-pce-segment-routing-03.txt as PCE WG Document

[Daniele Ceccarelli]

Yes, support

BR
Daniele

 -Original Message-
 From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of JP Vasseur (jvasseur)
 Sent: domenica 14 settembre 2014 12:06
 To: pce@ietf.org
 Subject: [Pce] Adopting of draft-sivabalan-pce-segment-routing-03.txt as
 PCE WG Document
 
 Dear WG,
 
 We had several discussions showing a good consensus adopting draft-
 sivabalan-pce-segment-routing-03.txt and this work has considerably
 progressed in other WG.
 
 Are you in favor of adopting draft-sivabalan-pce-segment-routing-03.txt as a
 PCE WG document ?
 
 Thanks.
 
 JP and Julien.
 
 

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