Re: [Pce] Adoption of draft-minei-pce-stateful-sync-optimizations as PCE WG Document?

[Jeff Tantsura]

Yes/support

Regards,
Jeff

 On Mar 4, 2014, at 6:12 PM, Julien Meuric julien.meu...@orange.com wrote:
 
 Dear WG,
 
 As discussed during the PCE WG meeting today, we had some support for 
 adopting draft-minei-pce-stateful-sync-optimizations-01 as a PCE WG item.
 
 Would you be in favor/opposed (and why if you want to justify) of adopting it 
 as a WG document?
 
 Thanks.
 
 JP and 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] FW: New Version Notification for draft-lee-pce-transporting-te-data-00.txt

[Jeff Tantsura]

Hi,

While i find BGP-LS much more suitable for the distribution of TE data due to:
-BGP is well understood (operations/ troubleshooting, etc); sync, HA issues had 
be solved 
-Policies framework is comprehensive
-BGP infra in most cases is already in place
-RR construct provides hierarchy
-many more to mention
 
For the cases where BGP is not wanted (perceived as too complex/ doesn't 
support data types needed)/ PCE infra has been deployed and practices well 
understood it would make sense to use it.

From use cases prospective i think it only addresses (i), the rest could be 
addressed similarly well by BGP,  optical extensions are to come.

Regards,
Jeff

 On Jul 2, 2014, at 2:51 PM, Leeyoung leeyo...@huawei.com wrote:
 
 Hi, 
 
 We have just published a new PCE draft concerning alternative ways of 
 transporting TE data that may not depend on IGP-TE or BGP-LS. 
 
 The motivation for this work is a timely update of TE data directly from 
 nodes to PCE(s) to support scenarios like:
 
 (i) networks that do not support IGP-TE or BGP-LS but want to implement PCE.
 (ii) applications that require accurate and timely TE data that current 
 convergence time associated with flooding is not justified.  
 (iii) reduction of node OH processing of flooding mechanisms (esp. optical 
 transport networks where there are large amounts of traffic data and 
 constraints due to OTN/WSON/Flexi-grid, etc. Note that also BGP-LS is not 
 supported in optical transport networks today)
 
 Your comment will always be appreciated. 
 
 Thanks,
 Young (on behalf of other co-authors)
 
 
 -Original Message-
 From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
 Sent: Wednesday, July 02, 2014 4:32 PM
 To: Greg Bernstein; Dhruv Dhody; Greg Bernstein; Zhenghaomian; Dhruv Dhody; 
 Leeyoung; Leeyoung; Zhenghaomian
 Subject: New Version Notification for 
 draft-lee-pce-transporting-te-data-00.txt
 
 
 A new version of I-D, draft-lee-pce-transporting-te-data-00.txt
 has been successfully submitted by Young Lee and posted to the IETF 
 repository.
 
 Name:draft-lee-pce-transporting-te-data
 Revision:00
 Title:PCEP Extensions in Support of Transporting Traffic Engineering 
 Data
 Document date:2014-07-02
 Group:Individual Submission
 Pages:20
 URL:
 http://www.ietf.org/internet-drafts/draft-lee-pce-transporting-te-data-00.txt
 Status: 
 https://datatracker.ietf.org/doc/draft-lee-pce-transporting-te-data/
 Htmlized:   
 http://tools.ietf.org/html/draft-lee-pce-transporting-te-data-00
 
 
 Abstract:
   In order to compute and provide optimal paths, Path Computation
   Elements (PCEs) require an accurate and timely Traffic Engineering
   Database (TED). Traditionally this TED has been obtained from a link
   state routing protocol supporting traffic engineering extensions.
   This document discusses possible alternatives to TED creation. This
   document gives architectural alternatives for these enhancements and
   their potential impacts on network nodes, routing protocols, and
   PCE.
 
 
 
 
 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

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

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

[Jeff Tantsura]

Hi,

Support as co-author.
Thanks!

Regards,
Jeff

 On Sep 14, 2014, at 3:07 AM, JP Vasseur (jvasseur) jvass...@cisco.com 
 wrote:
 
 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

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

Re: [Pce] Adoption of draft-sivabalan-pce-lsp-setup-type-02.txt as a PCE WG Document

[Jeff Tantsura]

Yes/support

Cheers,
Jeff





We had several discussions showing a good consensus adopting
draft-sivabalan-pce-lsp-setup-type-02.txt and this work
has considerably progressed in other WG.

Are you in favor of adopting draft-sivabalan-pce-lsp-setup-type-02.txt as
a PCE WG document ?

Thanks.

JP and 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] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

[Jeff Tantsura]

Yes/support

Cheers,
Jeff




-Original Message-
From: julien.meu...@orange.com julien.meu...@orange.com
Organization: Orange
Date: Monday, December 1, 2014 at 9:18 AM
To: pce@ietf.org pce@ietf.org
Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and
draft-ietf-pce-stateful-sync-optimizations-01

Dear all,

As planned, this message ignites a 3-week WG Last Call on both
draft-ietf-pce-pce-initiated-lsp-02 and
draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday
December 22 at 11:59 PM, HST.

Please send your comments to the PCE mailing list.

Thanks,

JP  Julien


__
___

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.

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

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

Re: [Pce] Comment on draft-ietf-pce-segment-routing-01

[Jeff Tantsura]

I fully agree with the comments and thanks Jon for bringing it up.
We will work to address it.

Regards,
Jeff

On Mar 25, 2015, at 6:44 PM, Dhruv Dhody 
dhruv.i...@gmail.commailto:dhruv.i...@gmail.com wrote:

+1,  I agree with Jon.

Perhaps a new METRIC type for MSD?

Regards,
Dhruv

On Wed, Mar 25, 2015 at 6:23 PM, Jonathan Hardwick 
jonathan.hardw...@metaswitch.commailto:jonathan.hardw...@metaswitch.com 
wrote:
Hi Jeff

I just wanted to clarify the comment that I made at the mic today as we seemed 
to be talking at cross-purposes.

The draft sets a maximum SID depth in the Open message, which effectively 
creates an implicit constraint on all queries that are sent over the PCEP 
session, such that returned paths must not have a SID stack depth greater than 
the MSD.  I think this is wrong, and that the MSD should instead be sent as an 
explicit constraint on each query.  Here is my reasoning.

In the PCE architecture it is wrong to assume that the PCC and the ingress 
router are the same device.  There are at least two cases where it is not.

• In some network management architectures, the PCC is a network 
management tool.  The network management tool may have many ingress routers in 
its jurisdiction, each with a different MSD, so it is not true to say that the 
MSD is a constant for the PCC-PCE session.

• In inter-domain routing there is PCE-PCE communication between 
domains.  One of the PCEs plays the role of PCC and is acting on behalf of all 
edge routers in its domain (or perhaps some domain further upstream).  Again, 
the MSD is not constant on the PCE-PCE session.

I don’t think that we should rule either of these scenarios out of segment 
routing, even if they are not the first scenarios that everyone is targeting.  
At some point we will want to do them and we do not want to re-do the work that 
we are doing today to make them work.

Best regards
Jon


___
Pce mailing list
Pce@ietf.orgmailto: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] Comment on draft-ietf-pce-segment-routing-01

[Jeff Tantsura]

Hi,

Great discussion!

Let’s try no to mix things.

  1.  Entropy labels (LB for ECMP/LAG) use case has been described in 
draft-ietf-mpls-spring-entropy-label, this ID defines new capability - RLD - 
Readable Label Depth which is used to define how ELI, EL (or multiple of 
those) should be instantiated.
  2.  draft-xu-isis-mpls-elc and draft-xu-ospf-mpls-elc define RLSDC -Readable 
Label Stack Deepth Capability which is used to advertise the capability of the 
router to read a label stack of a particular depth.

Back to the original discussion – Jon is right – MSD is significant on the 
ingress only since only ingress knows total stack depth and is in charge of 
pushing it.
Adrian’s proposal looks good to me – we will discuss it among coauthors and 
come back ASAP.

Thanks everyone for your valuable comments!

P.S. We should really agree on terminology :)

Cheers,
Jeff

From: Olivier Dugeon 
olivier.dug...@orange.commailto:olivier.dug...@orange.com
Date: Thursday, March 26, 2015 at 6:46 AM
To: Jonathan Hardwick 
jonathan.hardw...@metaswitch.commailto:jonathan.hardw...@metaswitch.com, 
rabah.gued...@orange.commailto:rabah.gued...@orange.com 
rabah.gued...@orange.commailto:rabah.gued...@orange.com
Cc: 
draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org
 
draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org,
 pce@ietf.orgmailto:pce@ietf.org pce@ietf.orgmailto:pce@ietf.org, Jeff 
Tantsura jeff.tants...@ericsson.commailto:jeff.tants...@ericsson.com
Subject: Re: [Pce] Comment on draft-ietf-pce-segment-routing-01

Hello Jon,

Yes you agree. From the pure Segment Routing and MPLS point of view. Now, 
looking to load balancing, it is quiet different. When you setup LAG or Load 
Balancing, the router perform a hash on the packet header to determine on which 
interface to send the packet. In general, the has allow a router to send all 
packets that belongs to the same session goes to the same interface / path. 
Now, some hardware limitation impose a limitation on the size of the label 
stack in order to continue to operate the hash function on the IP header 
located after the label stack. In the label stack is too huge, the hash 
function will operate across the beginning of the IP header and the end of 
label stack resulting on non optimal session segregation. In some case it could 
not be acceptable and lead into problem from an operational point of view. For 
example, it could cause some packets de-ordering (packets of the same session 
not follow the same path) that could be not supported by some application e.g. 
VoIP.

So, if for example a PE router accept a MSD of 10 labels and a P router accept 
a MSD of 5 labels, the computed SR path must take into account that when 
reaching the P router, le Segment packet must not have a label stack greater 
than 5 (or 6 depending if the hash is perform before or after the POP 
operation).

Hope this clarify our requests.

Regards

Olivier

Le 26/03/2015 14:24, Jonathan Hardwick a écrit :
Olivier, Rabah,

Please could you clarify something for me?  I’m not sure that the MSD of the 
intermediate nodes has the same significance as the MSD of the ingress node.  
My understanding is that the ingress node is often limited by hardware in the 
maximum depth of the SID stack that it can push onto each packet.  The 
intermediate nodes do not have to push SIDs – I thought that they would just 
route on the top-most SID in the stack and sometimes remove the top-most SID 
from the stack.  If that’s true then the MSD path constraint does not apply to 
them.  Have I misunderstood?

Best regards
Jon


From:rabah.gued...@orange.commailto:rabah.gued...@orange.com 
[mailto:rabah.gued...@orange.com]
Sent: 26 March 2015 06:18
To: DUGEON Olivier IMT/OLN; Jonathan Hardwick; Jeff Tantsura
Cc: 
draft-ietf-pce-segment-rout...@tools.ietf.orgmailto:draft-ietf-pce-segment-rout...@tools.ietf.org;
 pce@ietf.orgmailto:pce@ietf.org
Subject: RE: [Pce] Comment on draft-ietf-pce-segment-routing-01

Hi,
I totally agree with Olivier and Jonathan on this.
to encompass all the varieties of PCE/PCC architectures, the MSD should be 
considered as additional constraint by the path computation engine just like 
the BANDWIDTH,
the only scenario I can think of where the MSD must be announced by the PCC is 
inter-PCE collaboration and the right place would be for it is PCReq.


I Agree with Olivier a support his proposition.
considering only the PCC MSD and not the intermediate nodes by the path 
computation engine will result in paths that don’t behave as expected, 
(specially for load balancing
in a loose path scenario ),the PCE must have in its TED all the MSDs of all the 
nodes (PE and P) in its domain, therefore the MSD should advertised by the IGP 
(OSPF, ISIS,
BGP-LS) just like the SRLGs, where the path computation engine will consider  
the  MSDs of the ingress and intermediate to compute the path.



Best regards

Re: [Pce] Experimental Codepoints allocation in PCEP registry

[Jeff Tantsura]

Hi Adrian,

8 sounds like a good number.

Cheers,
Jeff

On 6/16/16, 9:25 AM, "Pce on behalf of Dhruv Dhody" <pce-boun...@ietf.org on 
behalf of dhruv.dh...@huawei.com> wrote:

>Hi Adrian,
>
>> How would you all feel about 8? (My instinct is to push for 4, but I can
>> pre-emptively compromise :-)
>
>I can work with 8 :)
>
>Regards,
>Dhruv
>
>> -Original Message-
>> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
>> Sent: 15 June 2016 23:52
>> To: Dhruv Dhody <dhruv.dh...@huawei.com>; 'Ramon Casellas'
>> <ramon.casel...@cttc.es>; pce@ietf.org
>> Subject: RE: [Pce] Experimental Codepoint allocation in PCEP registry
>> 
>> To Ramon's point...
>> 
>> > We do need to reach a consensus on what range to set aside.
>> 
>> Yes, we do. Both to satisfy ourselves and to get past the current IESG (not
>> the one that approved the MANET registry).
>> 
>> I think you captured the essence. There should be enough code points to run
>> the parallel experiments that need to be run together, but not so many that
>> experiments that don't need to be run at the same time can grab values and
>> expect to keep them. Essentially, before running an experiment all
>> participants should get together to agree what values to use, and then when
>> the experiment is over they should consider the values to have no meaning
>> (until the next and completely different experiment).
>> 
>> As far as I can see, 30 messages looks like a complete orgy of 
>> experimentation!
>> Four times more active experimentation in one experimental network than in
>> the whole of the standardised and soon-to-be standardised history of PCEP.
>> 
>> How would you all feel about 8? (My instinct is to push for 4, but I can
>> pre-emptively compromise :-)
>> 
>> Adrian
>> 
>> > -Original Message-
>> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
>> > Sent: 10 June 2016 11:03
>> > To: Ramon Casellas; pce@ietf.org
>> > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP registry
>> >
>> > Hi Ramon,
>> >
>> > > -Original Message-
>> > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ramon Casellas
>> > > Sent: 10 June 2016 14:42
>> > > To: pce@ietf.org
>> > > Subject: Re: [Pce] Experimental Codepoint allocation in PCEP
>> > > registry
>> > >
>> > > Hi Dhruv, Jeff, all
>> > >
>> > > Indeed. Having been involved in PCE-related experimental and
>> > > research activities I would welcome this and could be very helpful.
>> > > It will not solve the issues but at least it defines the ranges.
>> > >
>> > > I can't provide much feedback, just curious about the rationale to
>> > > allocate a given range e.g. 224-255 > 30 messages, etc.
>> >
>> > [Dhruv] You hit the jackpot we wanted to get the feedback of the
>> > WG about this.
>> >
>> > IMHO we need to strike a right balance that there are enough
>> > codepoints set aside for multiple parallel experimentations at a given
>> > time, and not to give
>> up a
>> > big chunk out for experimentation that it hinders IANA allocation.
>> >
>> > We currently have 9 messages set by IANA, some 4 new messages in queue
>> > to be sent to IANA, 13/255 ... so we do not have to worry about
>> > running out any time soon :)
>> >
>> > BTW I could find one instance in MANET where a similar range is
>> > allocated -
>> > https://tools.ietf.org/html/rfc5444#section-6.2
>> >
>> > We do need to reach a consensus on what range to set aside.
>> >
>> > Regards,
>> > Dhruv
>> >
>> > >
>> > > Best regards
>> > > Ramon
>> > >
>> > > On 10/06/2016 11:00, Jeff Tantsura wrote:
>> > > > Hi Dhruv,
>> > > >
>> > > > Support, very much needed!
>> > > >
>> > > > Thanks,
>> > > > Jeff
>> > > >
>> > > > On 6/9/16, 5:09 AM, "Pce on behalf of Dhruv Dhody"
>> > > > <pce-boun...@ietf.org
>> > > on behalf of dhruv.dh...@huawei.com> wrote:
>> > > >
>> > > >> Hi WG,
>> > > >>
>> > > >> In PCE IANA registry [http://www.iana.org/assignments/pcep] we do
>> > > >> not
>> > > have any codep

Re: [Pce] Query on Usage of LSP Identifier TLV in SR

[Jeff Tantsura]

Hi Robert,

I disagree with you, I don’t think we need RSVP-TE semantics here, in the 
implementations I'm aware of LSP Identifiers TLV is not used.
END-POINTS object is used to identify the tunnel endpoint addresses.

I do agree that SR draft should be clear about this and we will update it.

Cheers,
Jeff

From: Robert Varga >
Date: Thursday, October 22, 2015 at 04:29
To: Dhruv Dhody >, 
"draft-ietf-pce-segment-rout...@ietf.org"
 
>,
 
"draft-ietf-pce-stateful-...@tools.ietf.org"
 
>
Cc: "pce@ietf.org" >, 
"pce-cha...@tools.ietf.org" 
>
Subject: Re: [Pce] Query on Usage of LSP Identifier TLV in SR

On 10/12/2015 07:58 AM, Dhruv Dhody wrote:
Hi Authors,

In the stateful PCE draft [1], it says –
The LSP Identifiers TLV MUST be included in the LSP object in PCRpt
messages for RSVP-signaled LSPs.

The SR draft [2] did not mention anything about LSP Identifier TLV.
And in implementations that I am aware of, SR-TE LSP still uses the 
LSP-Identifier TLV. Is that correct? (I personally think so!!)

If yes, do you think there is a need to update –

-  [1] to say all LSPs (and not just RSVP-signaled).

-  Or [2] to say that LSP-Identifier TLV are also applicable to SR and MUST 
be included.


The wording in stateful draft is meant to proscribe behavior for RSVP (as that 
is what RFC5440 assumes), while allowing different setup mechanisms 
(https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/) specify their 
own LSP identifier format.

In this spirit I think the SR draft should be updated to explicitly state that 
SR reuses the same identifier format as RSVP (or whatever is appropriate).

Bye,
Robert

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

Re: [Pce] Adoption of draft-pkd-pce-pcep-yang-06

[Jeff Tantsura]

Support as co-author
 
Cheers,
Jeff
 

On 8/12/16, 02:43, "Pce on behalf of Julien Meuric"  wrote:

Hi all,

During the joint TEAS-MPLS-PCE Yang session in Berlin, we had a clear 
consensus in the room on the interest for the aforementioned I-D. We now 
need to see if the mailing list confirms this consensus. As a result, do 
you think that draft-pkd-pce-pcep-yang-06 is a right foundation for a 
PCE WG document? As usual, comments are very welcome, especially if you 
do not support the adoption.

Thanks,

JP, Jon & 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] Poll for adoption: draft-litkowski-pce-association-diversity

[Jeff Tantsura]

yes/support

 

 

Cheers,

Jeff

 

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com] 
Sent: Wednesday, January 11, 2017 8:45 AM
To: pce@ietf.org
Cc: pce-cha...@ietf.org; draft-litkowski-pce-association-divers...@ietf.org
Subject: Poll for adoption: draft-litkowski-pce-association-diversity

 

This is start of a two week poll on making 
draft-litkowski-pce-association-diversity-01 a PCE working group document.

https://www.ietf.org/id/draft-litkowski-pce-association-diversity-01.txt

 

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 Wednesday January 25.

 

Thanks,

Jon, JP and 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] Poll for adoption: draft-dhody-pce-stateful-pce-auto-bandwidth-09

[Jeff Tantsura]

Yes/support

 

 

Cheers,

Jeff

 

 

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

Re: [Pce] Poll for adoption: draft-dhody-pce-pcep-exp-codepoints-03

[Jeff Tantsura]

yes/support

 

Cheers,

Jeff

 

 

From: Pce  on behalf of 
Date: Monday, April 10, 2017 at 09:10
To: 'Dhruv Dhody' , Jonathan Hardwick 
, 
Cc: , 
Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-pcep-exp-codepoints-03

 

Yes, support! 

 

Also a co-author; and tired of reviewing PCE code on GitHub to see who has been 
code swatting. 

 

BR, Dan. 

 

From: Dhruv Dhody [mailto:dhruv.i...@gmail.com] 
Sent: 10 April 2017 17:01
To: Jonathan Hardwick ; pce@ietf.org
Cc: pce-cha...@ietf.org; draft-dhody-pce-pcep-exp-codepoi...@ietf.org
Subject: Re: Poll for adoption: draft-dhody-pce-pcep-exp-codepoints-03

 

Yes/Support! 

Dhruv (as co-author)

 

 

On Monday 10 April 2017 04:08 PM, Jonathan Hardwick wrote:

All,

 

This is the start of a two week poll on making 
draft-dhody-pce-pcep-exp-codepoints-03 a PCE working group document.

https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/

 

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 Monday, April 24.

 

Many thanks,

Jon

 

 

___ 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] PCEP as an SDN controller protocol?

[Jeff Tantsura]

++1

 

Cheers,

Jeff

 

From: Pce  on behalf of Cyril Margaria 

Date: Tuesday, July 25, 2017 at 12:25
To: LITKOWSKI Stephane DTF/DERX 
Cc: "pce@ietf.org" , "pce-cha...@ietf.org" 
Subject: Re: [Pce] PCEP as an SDN controller protocol?

 

+1, 

 

PCEP is rather efficient at dealing with paths and constraints. 

PCE-CC , as someone mentioned earlier, can be seen as 1-hop LSPs, there could 
be minimum protocol extensions.  

 

PCEP-LS is redoing links-state flooding over PCEP, using the same elements as 
existing protocols. This sounds OK as an experiment but the operational or 
scale advantages to it seems very limited. 

 

I don't think we should overload PCEP to carry IGP information (nor device 
configuration) 

 

My 2 cents

Cyril

 

 

On 24 July 2017 at 08:02,  wrote:

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 J ?

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 fully-fledged SDN 
protocol.  With these proposals, one can envision a network in which there is 
no traditional control plane.  PCEP is used to communicate the current network 
state and to program flows.  These proposals have their roots in the ACTN and 
PCECC architectures that are adopted within the TEAS working group.  TEAS is 
very much assuming that this is the direction that we want to take PCEP in.  
However, there are two procedural issues, as I see it.

1.  We have not had an explicit discussion in the PCE WG about whether we 
want to take PCEP in this direction.  We have had a few lively debates on 
specific cases, like PCEP-LS, but those cases represent the “thin end of the 

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

[Jeff Tantsura]

We all know – every protocol has its strong and less strong sides, however the 
properties required for a distributed device2device communication are quite 
different from device2controller environment and should be evaluated as such.

There’s a long list of pros and cons for either environments (objective 
functions) as well operational preferences, domain knowledge, and such

 

Most of us here are biased ☺ 

To put it short – I believe there’s enough people who are interested in working 
on PCEP to extend it, personally I see value in having PCEP next to any other 
SBI’s mentioned below, however what I don’t want, is to overload semantics of 
PCEP (aka BGP kitchen sink ☺).

 

Cheers,

Jeff

 

From: Pce  on behalf of Igor Bryskin 

Date: Monday, July 24, 2017 at 14:52
To: "stephane.litkow...@orange.com" , Jonathan 
Hardwick , "pce@ietf.org" 
Cc: "pce-cha...@ietf.org" 
Subject: Re: [Pce] PCEP as an SDN controller protocol?

 

Hi Stephanie,

 

You said:

< Why not limiting PCEP to path programming and path policies (traffic steering 
on path…) ?

 

But why not to use for these purposes RESTCONF or gRPC/protobuffs? Do you see 
value in using explicit model based SBIs vs implicit (TLV-) based protocols 
such as  PCE?

 

Cheers,,

Igor

 

 

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: Monday, July 24, 2017 8:03 AM
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 J ?

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 

Re: [Pce] Final IPR Check for draft-ietf-pce-lsp-setup-type

[Jeff Tantsura]

Julien,

I am not aware of any IPR that applies to this draft.
 
Cheers,
Jeff

-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: 16 May 2017 08:55
To: draft-ietf-pce-lsp-setup-t...@ietf.org
Cc: pce@ietf.org
Subject: Final IPR Check for draft-ietf-pce-lsp-setup-type

Dear authors,

 

Could you please send an email to the PCE mailing list saying whether you 
are aware of any IPR that applies to draft-ietf-pce-lsp-setup-type and, if so, 
if it has been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not 
aware of any IPR that applies, please reply saying "I am not aware of any IPR 
that applies to this draft".

 

A reply is required from each of you before we can proceed.

 

Many thanks,


Julien




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

Re: [Pce] Is there any activity related to PCE graceful restart?

[Jeff Tantsura]

+1 Adrian.
complexity associated with GR (additional state/signaling/etc) wouldn’t be 
justified, given existing means to provide synchronization. 
 
Cheers,
Jeff
 

On 6/19/17, 08:21, "Pce on behalf of Adrian Farrel"  wrote:

Hi Sasha,

> However, our primary interest is the control plane (including PCC) 
restart in
a 
> network element with separated  control and forwarding planes. 

Yup. I assumed control plane restart was the issue.

> Specifically, my colleagues and I try to understand, how to make such a
restart
> non-traffic affecting while:
> - The network uses Segment Routing for setting up paths computed by the 
PCE.
>This means that these paths are only known to their respective head-end
nodes.
>This situation is different from the scenario where RSVP-TE is used to
signal these
>paths, since they cannot be re-learned from the neighbors as part of 
the
RSVP-TE
>graceful restart procedures

OK, so you are less worried about PCE restart than about restart of control
plane elements in the network.
But you are using SR so there is no state (or rather only routing state) in 
the
network. The state for the path is at the PCE and at the headend, and 
nowhere
else.
So, if a network node restarts, it doesn't matter.
If the headend loses state it must relearn it from the PCE. If the PCE loses
state it must relearn it from the headend.

> - The protocols used for distributing SR-related information (i.e., IGP 
and
BGP SR 
>extensions) are GR-capable, and GR for them is enabled in the network

Right. So that is additional reason to not worry about restart elsewhere in 
the
network

> - The PCE is an active stateful PCE, i.e., it instructs the head-end 
node, 
>which paths should be set up without any requests coming from the
>nodes. 

This makes life easier because we know that the PCE has pushed all of the 
paths.
So restart is just  matter of pushing all of those paths again.

It is an implementation question whether the restart has preserved 
forwarding
plane state. In this case, forwarding plane state is "classification"
information, that is "packets of this type get this SID stack".

If the forwarding state is saved, data can continue to flow. Restart is 
about
making sure that the PCE and headend are in synch.
If forwarding state is not saved, the PCE must resynch the state before the
headend can use it.

It is certainly the case that the failure of a PCEP session does not result 
in
discard of headend state. That is, the headend can continue to operate 
using any
state that was pushed by a PCE even after that PCE has failed. This might be
termed "non-stop forwarding" in some protocols in the middle of the 
network, but
is just normal business for a stateful active PCE.

> Hopefully this clarifies the context for our question.

It does.

> It may well be that the requirement for non-traffic affecting control 
plane
> restart can be addressed without any changed to the existing protocols. 
> Alternatively, it  is possible that some minor changes (like making the 
PCE
> aware of separation between the control and forwarding planes, negotiation
> of GR capabilities and grace periods etc.) are required. 
>
> Any inputs would be highly appreciated.

My take-away from the swamp of text above is that:
- Network nodes don't need to do anything special except in their
   relationship with the PCE
- A stateful PCE needs to resynch pushed paths for all paths that it has
   responsibility for upon reconnection with a network node

Now we can go and look at the stateful I-D and the PCE-initiated I-D to see
whether we already have enough stuff in the protocol. My belief is that we 
do.

Cheers,
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

Re: [Pce] Poll for adoption: draft-dhodylee-pce-stateful-hpce

[Jeff Tantsura]

yes/support

 

 

Cheers,

Jeff

 

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Thursday, June 01, 2017 9:25 PM
To: pce@ietf.org
Cc: draft-dhodylee-pce-stateful-h...@ietf.org; pce-cha...@ietf.org
Subject: [Pce] Poll for adoption: draft-dhodylee-pce-stateful-hpce

 

All,

 

This is the start of a two week poll on making 
draft-dhodylee-pce-stateful-hpce-03 a PCE working group document.

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

 

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, June 15.

 

Many thanks,

Jon

 

___ 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] Poll for adoption: draft-dhody-pce-applicability-actn-02

[Jeff Tantsura]

yes/support

 

Cheers,

Jeff

 

 

From: Pce  on behalf of Sureshbr 
Date: Monday, May 1, 2017 at 21:23
To: "Zhangxian (Xian)" , Jonathan Hardwick 
, "pce@ietf.org" 
Cc: "draft-dhody-pce-applicability-a...@ietf.org" 
, "pce-cha...@ietf.org" 

Subject: Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02

 

Support.

 

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Zhangxian (Xian)
Sent: 26 April 2017 09:04
To: Jonathan Hardwick; pce@ietf.org
Cc: draft-dhody-pce-applicability-a...@ietf.org; pce-cha...@ietf.org
Subject: [Pce] 答复: Poll for adoption: draft-dhody-pce-applicability-actn-02

 

yes/support.

 

Regards,

Xian

 

发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Jonathan Hardwick
发送时间: 2017年4月26日 0:26
收件人: pce@ietf.org
抄送: draft-dhody-pce-applicability-a...@ietf.org; pce-cha...@ietf.org
主题: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02

 

All,

 

This is the start of a two week poll on making 
draft-dhody-pce-applicability-actn-02 a PCE working group document.

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

 

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, May 9.

 

Many thanks,

Jon

 

 

___ 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] Second WG Last Call for draft-ietf-pce-lsp-setup-type

[Jeff Tantsura]

As co-author  - yes/support

Regards,
Jeff

> On Nov 21, 2017, at 00:32, Julien Meuric  wrote:
> 
> Dear PCE WG,
> 
> Considering the concerns discussed on the list after the 1st WG Last
> Call, especially about the backward compatibility of the additional TLV
> (please see Jon's change list), this message starts a 2nd LC on
> draft-ietf-pce-lsp-setup-type-06. It will end on Monday December 4.
> 
> Thanks for your careful reviews,
> 
> 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] IPR Check on draft-ietf-pce-segment-routing

[Jeff Tantsura]

Julien,

I’m not aware of any IPR that applies to draft-ietf-pce-segment-routing.

Thanks,
Jeff
On Tue, Jan 16, 2018 at 06:11 Siva Sivabalan (msiva) 
wrote:

> I am not aware of any IPR that applies to this draft.
>
> Thanks,
> Siva
>
>
>
> -Original Message-
> From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> Sent: Tuesday, January 16, 2018 8:45 AM
> To: Julien Meuric ; pce@ietf.org
> Cc: draft-ietf-pce-segment-rout...@ietf.org
> Subject: RE: IPR Check on draft-ietf-pce-segment-routing
>
> I am not aware of any IPR that applies to this draft.
>
> Cheers
> Jon
>
> -Original Message-
> From: Julien Meuric [mailto:julien.meu...@orange.com]
> Sent: 15 January 2018 09:41
> To: draft-ietf-pce-segment-rout...@ietf.org
> Cc: pce@ietf.org
> Subject: IPR Check on draft-ietf-pce-segment-routing
>
> Dear authors of draft-ietf-pce-segment-routing,
>
> Could you please send an email to the PCE mailing list saying whether you
> are aware of any IPR that applies to draft-ietf-pce-segment-routing and, if
> so, if it has been disclosed in compliance with IETF IPR rules?
> (See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not
> aware of any IPR that applies, please reply saying "I am not aware of any
> IPR that applies to this draft".
>
> A reply is required from each of you before we can proceed.
>
> Thanks,
>
> Julien
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG LC of draft-ietf-pce-association-group

[Jeff Tantsura]

Yes/support

Cheers,
Jeff
On 2/1/18, 09:10, "Pce on behalf of Julien Meuric"  wrote:

Hi all,

This message initiates a 2-week WG last call for
draft-ietf-pce-association-group-04. Please review and share your
feedback on the PCE mailing list. This LC will end on Thursday February, 15.

Regards,

Jon & 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] WG adoption poll for draft-li-pce-pcep-flowspec-03

[Jeff Tantsura]

Adrian,

Would be my pleasure ;-)

Regards,
Jeff

> On Feb 20, 2018, at 12:53, Adrian Farrel <adr...@olddog.co.uk> wrote:
> 
> Jeff, I definitely agree with you about kitchen sinks.
> OTOH, in this case the lack of coordination is actually painful and creates a 
> mess since each vendor uses a different way to instruct its devices after a 
> PCinitiate has completed successfully.
>  
> A Deployment Considerations section sounds just the thing. Maybe we will lean 
> on you for text after adoption :-)
>  
> A
>  
>  
> From: Jeff Tantsura [mailto:jefftant.i...@gmail.com] 
> Sent: 20 February 2018 15:39
> To: adr...@olddog.co.uk; 'Jonathan Hardwick'; pce@ietf.org
> Cc: pce-cha...@ietf.org; draft-li-pce-pcep-flows...@ietf.org
> Subject: Re: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03
>  
> I’d “carefully” support the adoption, while functionality is needed, and 
> having complete set in a single protocol has its advantages (and complexity 
> associated), we already have one “kitchen sink” protocol, that has however 
> been designed to support 100M of entries and deal with bursty data, PCEP is 
> yet to get there. Deployment consideration section would be of great value.
>  
> Cheers,
> Jeff
> From: Pce <pce-boun...@ietf.org> on behalf of Adrian Farrel 
> <adr...@olddog.co.uk>
> Reply-To: <adr...@olddog.co.uk>
> Date: Tuesday, February 20, 2018 at 10:17
> To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>, <pce@ietf.org>
> Cc: <pce-cha...@ietf.org>, <draft-li-pce-pcep-flows...@ietf.org>
> Subject: Re: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03
>  
> Unsurprisingly, I also think we should adopt this drafts.
> To me it seems like a critical piece of function that we "forgot" when we 
> started to allow thee PCE to have control.
> AFAIK current implementations "bodge" around the issue backing up PCEP 
> messages with other control messages (such as Netconf) to say how the LSP 
> should be used.
> We need a consolidated approach.
>  
> Thanks,
> Adrian
>  
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
> Sent: 20 February 2018 13:34
> To: pce@ietf.org
> Cc: draft-li-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org
> Subject: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03
>  
> 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
___
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

[Jeff Tantsura]

I’d “carefully” support the adoption, while functionality is needed, and having 
complete set in a single protocol has its advantages (and complexity 
associated), we already have one “kitchen sink” protocol, that has however been 
designed to support 100M of entries and deal with bursty data, PCEP is yet to 
get there. Deployment consideration section would be of great value.

 

Cheers,

Jeff

From: Pce  on behalf of Adrian Farrel 

Reply-To: 
Date: Tuesday, February 20, 2018 at 10:17
To: Jonathan Hardwick , 
Cc: , 
Subject: Re: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03

 

Unsurprisingly, I also think we should adopt this drafts.

To me it seems like a critical piece of function that we "forgot" when we 
started to allow thee PCE to have control.

AFAIK current implementations "bodge" around the issue backing up PCEP messages 
with other control messages (such as Netconf) to say how the LSP should be used.

We need a consolidated approach.

 

Thanks,

Adrian

 

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 20 February 2018 13:34
To: pce@ietf.org
Cc: draft-li-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org
Subject: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03

 

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 

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

[Pce] Mail regarding draft-negi-pce-segment-routing-ipv6

[Jeff Tantsura]

Hi co-authors,

 

Few comments:

SRv6-PCE-CAPABILITY sub-TLV should be changed (MSD handling) to be aligned with 
section 3 of draft-bashandy-isis-srv6-extensions-03

Could you please elaborate on use of Function Codes at the head-end?

 

Thanks!

 

Cheers,

Jeff

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

Re: [Pce] [mpls] Comments on draft-ietf-mpls-spring-entropy-label

[Jeff Tantsura]

Hi,

 

Please see inline (MSD section).

Hope this clarifies, thanks!

 

Cheers,

Jeff

 

 

 

[jeff] both IGP drafts have identical description of the BMI-MSD:

“Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels a 
node is capable of imposing, including all service/transport/special labels.”

PCEP draft supports only a subset of overall MSD functionality and in general 
it is expected that this info would come from IGPs(BGP-LS).

However the functoriality provided by PCEP is inline with the  BMI-MSD 
definition in the IGP drafts, at the node granularity only though. 

 

 

3. Section 5 introduces the MSD concept. I wonder whether this concept is 
aligned with the MSD concept as defined in the PCEP-SR draft or the MSD concept 
as defined in the IGP-MSD draft. In PCEP-SR draft, it said "
The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label
   stack depth in the context of this document) that a PCC is capable of
   imposing on a packet.
 
In the IGP-MSD draft, it said "
MSD of type 1 (IANA Registry), called Base MSD is used to signal the
   total number of SIDs a node is capable of imposing, to be used by a
   path computation element/controller.  "
 
If I understand it correctly, the MSD in this draft==the MSD in PCEP-SR 
draft==the Base MSD (i.e., the MSD of type 1), No?
 

[SLI] Today, the two IGP drafts does not seem to agree on the definition
ISIS says:” Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels a node is capable of imposing, including all

   service/transport/special labels.”
OSPF says:” MSD of type 1 (IANA Registry) is used to signal the number of SIDs a
   node is capable of imposing, to be used by a path computation

   element/controller and is only relevant to the part of the stack

   created as the result of the computation.”

 

MSD is just MSD is defines a maximum number of labels to be pushed. This is the 
definition we use and it is compliant with the one used in PCEP-SR:
“The "Maximum SID Depth" (1
   octet) field (MSD) specifies the maximum number of SIDs (MPLS label

   stack depth in context of this document) that a PCC is capable of

   imposing on a packet.”

 

As we also say: “This includes any kind of labels (service, entropy, 
transport...).”, we are compliant with the BMI-MSD defined in IS-IS.

 

 

 

Best regards,

Xiaohu
_
 
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.
___ mpls mailing list 
m...@ietf..org https://www.ietf.org/mailman/listinfo/mpls 

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

Re: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt

[Jeff Tantsura]

Jon,

Looks great to me, thanks for the change!

Cheers,
Jeff

On 7/10/18, 04:19, "Pce on behalf of Jonathan Hardwick"  wrote:

Hi Mustapha

Yes, I think we can do that.  It's a small change and is backwards 
compatible.  I can update the draft when submissions re-open.  Here is my 
proposal for the revised section 5.5 text:

5.5.  METRIC Object

   A PCC MAY specify the MSD for an individual path computation request
   using the METRIC object defined in [RFC5440].  This document defines
   a new type for the METRIC object to be used for this purpose as
   follows:

   o  T = 11: Maximum SID Depth of the requested path.

   The PCC sets the metric-value to the MSD for this path.  The PCC MUST
   set the B (bound) bit to 1 in the METRIC object, which specifies that
   the SID depth for the computed path MUST NOT exceed the metric-value.

   If a PCEP session is established with a non-zero default MSD value, then 
the
   PCC MUST NOT send an MSD METRIC object with an MSD greater than
   the session's default MSD.  If the PCE receives a path computation 
request
   with an MSD METRIC object on a session which is greater than the 
session's
   default MSD, then it MUST consider the request invalid and send
   a PCErr with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value 9 ("MSD exceeds the default for the PCEP session").

Thanks
Jon

-Original Message-
From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
[mailto:mustapha.aissa...@nokia.com] 
Sent: 29 June 2018 19:19
To: Jonathan Hardwick ; pce@ietf.org
Subject: RE: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt

Hi Jon,
There is one issue which I would like to discuss and it came up during the 
EANTC multi-vendor interop in March 2018.

The rule for handling MSD in Section 5.5 seems to be overly restrictive. 
The MSD value advertised in the Open message is useful as an upper bound for 
both pce-initiated LSP and pcc-initiated LSP. However, PCC may want to set a 
MSD value for a specific pcc-initiated LSP which is lower than that in the Open 
Object. The rules in Section 5.5 do not allow that as the presence of the MSD 
Metric object in the path request message is errored if a non-zero MSD was 
included in the Open message. If on the other hand you set the MSD in the Open 
message to zero, PCE will not discover the MSD to enforce for pce-initiated LSP.

What I would like to propose is to relax the rule such that a path request 
is only errored when the MSD Metric value is higher than that in the Open 
message. That way we can achieve the desired behavior for both pce-initiated 
and pcc-initiated LSP.

Here is the relevant paragraph in Section 5.5:
"
   If a PCEP session is established with a non-zero MSD value, then the
   PCC MUST NOT send an MSD METRIC object.  If the PCE receives a path
   computation request with an MSD METRIC object on a session with a
   non-zero MSD value then it MUST consider the request invalid and send
   a PCErr with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value 9 ("Default MSD is specified for the PCEP session").
"

Mustapha.

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Friday, June 29, 2018 1:22 PM
To: pce@ietf.org
Subject: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt

This new version addresses the feedback received during working group last 
call.  My apologies for the long delay.
Many thanks to those who took the time to review and comment on this.  The 
result is that the draft has been substantially tightened and many ambiguities 
resolved.
I will be replying to the individual commenters today.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: 29 June 2018 18:20
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt


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

Title   : PCEP Extensions for Segment Routing
Authors : Siva Sivabalan
      Clarence Filsfils
  Jeff Tantsura
  Wim Henderickx
  Jon Hardwick
Filename: draft-ietf-pce-segment-routing-12.txt
Pages   : 32
Date: 2018-06-29

Abstract:
   Segment Routing (SR) enables any head-end node to select any path
   without relying on a

Re: [Pce] WG adoption poll for draft-ananthakrishnan-pce-stateful-path-protection-05

[Jeff Tantsura]

Yes/support


On Tue, Mar 27, 2018 at 04:10 Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> Dear PCE WG
>
>
>
> This is the start of a two week poll on making
> draft-ananthakrishnan-pce-stateful-path-protection-05 a PCE working group
> document.
>
>
> https://datatracker.ietf.org/doc/draft-ananthakrishnan-pce-stateful-path-protection/
>
>
>
> 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, April 10.
>
>
>
> Many thanks,
>
>
>
> Jon and 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] Fwd: PCE-BSID Question to the List

[Jeff Tantsura]

Dear PCE,

Following our presentation in Bangkok, 
https://datatracker.ietf.org/meeting/103/materials/slides-103-pce-23-binding-segment-00.pdf

The authors would like to ask the WG the following:


(1) Do we link the Binding SID to the PCEP SR capability? Currently we
can assign BSID for RSVP-TE LSP as well.

(2) Is WG happy with TE-PATH-BINDING TLV format?

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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Type (BT) | Binding Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Binding Value (continued) (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: TE-PATH-BINDING TLV

(3) Is there a use case for binding value as “index” in SRGB/SRLB?

Thanks!

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

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jeff Tantsura]

Hi John/Ben,

Happy New Year!

Both OSPF and IS-IS MSD documents have been published.
Wrt PCE - they merely state that if there’s no PCEP session between nodes
advertising and receiving this information, the receiving node has no other
means to learn the MSD of the advertising node, since it is local to the
node (while IGPs flood it to everyone).
Having this in the IGP drafts and PCE draft stating that if both protocols
advertise MSD, then IGP one should be preferred seemed clear enough (this
had been discussed).
>From granularity prospective - IGPs (BGP-LS) provide more details indeed as
per interface MSD could be advertised (PCEP could do node MSD only).

Hope this clarifies,
Jeff


On Sat, Jan 5, 2019 at 16:39 Benjamin Kaduk  wrote:

> On Fri, Dec 21, 2018 at 04:59:28PM +, Jonathan Hardwick wrote:
> > Hi Benjamin
> >
> > Sorry for the delayed response.  Please find replies to your comments
> below.
>
> And my apologies as well for waiting until after the holidays to
> counter-respond.
>
> > Best regards
> > Jon
> >
> >
> > Abstract
> >
> >This document specifies extensions to the Path
> >Computation Element Communication Protocol (PCEP) that allow a
> >stateful PCE to compute and initiate Traffic Engineering (TE) paths,
> >as well as a PCC to request a path subject to certain constraints and
> >optimization criteria in SR networks.
> >
> > Why are we talking about TE paths now instead of SR?
> >
> > [Jon] TE is the primary application for SR paths instantiated by a PCE.
> >
> > Section 1
> >
> >Several types of segment are defined.  A node segment represents an
> >ECMP-aware shortest-path to a specific node, and is always identified
> >uniquely within the SR/IGP domain.  [...]
> >
> > A path to a node is only going to be unique if the starting node is also
> included, is it not?
> >
> > [Jon] I suggest we reword this to make it clearer:
> >
> > OLD
> >A node segment represents an
> >ECMP-aware shortest-path to a specific node, and is always identified
> >uniquely within the SR/IGP domain.
> > NEW
> >A node segment uniquely identifies a specific node in the SR domain.
> >Each router in the SR domain associates a node segment with an
> >ECMP-aware shortest path to the node that it identifies.
> > END
>
> That works for me, thanks.
>
> > Section 3
> >
> > The sentences:
> >
> >In an SR network, the ingress node of an SR path prepends an SR
> >header to all outgoing packets.  The SR header consists of a list of
> >SIDs (or MPLS labels in the context of this document).
> >
> > Appear virtually unchanged in both the start of the first paragraph and
> the middle of the second paragraph; is this duplication really needed?
> >
> > [Jon] No - we'll remove the redundant text.
> >
> >A PCC MAY include an RRO containing the recorded LSP in PCReq and
> >PCRpt messages as specified in [RFC5440] and [RFC8231], respectively..
> >This document defines a new RRO subobject for SR networks.  The
> >methods used by a PCC to record the SR-TE LSP are outside the scope
> >of this document.
> >
> > It's not entirely clear that we need to define a standard container to
> carry site-local data when a site-local container could also be used.
> >
> > [Jon] Sorry, I don't understand your comment.  The RRO is an existing
> PCEP object whose subobjects are used to describe the actual path taken by
> an LSP.  We are adding subobjects to represent SIDs.
>
> I'm going from memory, and it's been some time since I read the document
> (so this could well be wrong), but I think I was thinking something like
> "we're defining a new type of subobject to represent SIDs, but the contents
> of that subobject are interpreted in a site-local manner.  How is this
> different from just having site-local subobjects, with both the subobject
> type and its contents being site-local matters?"  But this was just a
> non-blocking comment to start with, so if it doesn't make sense (or any
> other reason, really), feel free to drop the discussion -- I won't mind.
>
> > Section 5.2
> >
> > Please expand SRP (and RP, for that matter) on first usage.
> > (Interestingly,
> https://www.rfc-editor.org/materials/abbrev.expansion.txt
> > does not seem to have the correct expansion for this usage.)
> >
> > [Jon] Will do.
> >
> > Section 5.3.1
> >
> >   *  C: If the M bit and the C bit are both set to 1, then the TC,
> >  S, and TTL fields in the MPLS label stack entry are specified
> >  by the PCE.  However, a PCC MAY choose to override these values
> >  according its local policy and MPLS forwarding rules.  If the M
> >  bit is set to 1 but the C bit is set to zero, then the TC, S,
> >  and TTL fields MUST be ignored by the PCC.  The PCC MUST set
> >  these fields according to its local policy and MPLS forwarding
> >  rules.  [...]
> >
> > Must be ignored in incoming messages received from where?
> >

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jeff Tantsura]

Hi Julien,

Happy New Year to you too.
There’s a slight difference between limitless (e.g. unlimited) and limit
has not been been imposed (not configured/unknown/etc).
I think  “limitless” doesn’t convey the exact meaning. In simple terms - if
L=1, don’t use MSD as a constraint in the path computation.

Thanks,
Jeff

On Fri, Jan 4, 2019 at 02:28  wrote:

> Hi guys and happy new year! :-)
>
> Would it temper the confusion below if we added the term "limitless" to
> the L flag definition (section 5.1.1.)?
>
> My 2 cents,
>
> Julien
>
>
> On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > I believe it is too late to change but I find L=1 meaning "no limit" is
> *very* confusing. For me L stands for Limit and when L=1 there is a limit,
> when L=0 there is none.
> >
> > [Jon] Agree, both that it is confusing and too late to change :-)
>
>
>
> _
>
> 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

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jeff Tantsura]

+1 Jon

Cheers,
Jeff
On Jan 10, 2019, 2:58 AM -0800, Jonathan Hardwick 
, wrote:
> Hi Julien
>
> At the moment, the L bit is simply called "the L bit" (not "limit" or 
> "limitless") and is defined like this:
>
> * L: A PCC sets this bit to 1 to indicate that it does not impose
> any limit on the MSD.
>
> Although it might be the opposite of what you'd expect, I think the 
> definition is nevertheless clear as it is written.
>
> Cheers
> Jon
>
> -Original Message-
> From: Julien Meuric 
> Sent: Monday, 7 January, 2019 9:37 AM
> To: Jeff Tantsura 
> Cc: Dhruv Dhody ; Jonathan Hardwick 
> ; Martin Vigoureux 
> ; The IESG ; 
> draft-ietf-pce-segment-rout...@ietf.org; pce@ietf.org
> Subject: Re: Martin Vigoureux's No Objection on 
> draft-ietf-pce-segment-routing-14: (with COMMENT)
>
> Hi Jeff,
>
> You're right. I certainly don't want to change the specification, nor to add 
> another ambiguity. I was just looking for a mnemonic to mitigate the 
> confusion pointed out by Martin, to be considered between bracket (leaving 
> the definition as is).
> Would "limit-blind" make sense?
>
> Cheers,
>
> Julien
>
>
> On 06/01/2019 20:20, Jeff Tantsura wrote:
> > Hi Julien,
> >
> > Happy New Year to you too.
> > There’s a slight difference between limitless (e.g. unlimited) and
> > limit has not been been imposed (not configured/unknown/etc).
> > I think  “limitless” doesn’t convey the exact meaning. In simple terms
> > - if L=1, don’t use MSD as a constraint in the path computation.
> >
> > Thanks,
> > Jeff
> >
> > On Fri, Jan 4, 2019 at 02:28  > <mailto:julien.meu...@orange.com>> wrote:
> >
> > Hi guys and happy new year! :-)
> >
> > Would it temper the confusion below if we added the term
> > "limitless" to
> > the L flag definition (section 5.1.1.)?
> >
> > My 2 cents,
> >
> > Julien
> >
> >
> > On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > > I believe it is too late to change but I find L=1 meaning "no
> > limit" is *very* confusing. For me L stands for Limit and when L=1
> > there is a limit, when L=0 there is none.
> > >
> > > [Jon] Agree, both that it is confusing and too late to change
> > :-)
> >
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption Call for draft-negi-pce-segment-routing-ipv6

[Jeff Tantsura]

I support the adoption and willing to work on it.

The Function Code section is not well specified and should refer to 
draft-filsfils-spring-srv6-network-programming that has requested new IANA 
sub-registry "SRv6 Endpoint Behaviors”.
In general it is unclear why do we need them and what does “maintainability” 
mean in that context.

Cheers,
Jeff
On Feb 21, 2019, 10:47 PM -0800, Dhruv Dhody , wrote:
> Hi WG,
>
> Please read & review draft-negi-pce-segment-routing-ipv6-04 [1] and
> send your comments to the mailing list.
>
> 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? Do you plan to implement it?
>
> This poll will run until 8th March.
>
> Thanks,
> PCE Chairs
>
> [1] 
> https://datatracker.ietf.org/doc/draft-negi-pce-segment-routing-ipv6/?include_text=1
>
> ___
> 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] WG Last Call completed for draft-ietf-pce-applicability-actn

[Jeff Tantsura]

Yes/support

Cheers,
Jeff

> On Mar 7, 2019, at 1:35 AM, Dhruv Dhody  wrote:
> 
> Hi Adrian, WG, 
> 
> We have posted a new version -09 that addresses WG LC comments (from Adrian 
> and Dan). 
> 
> I-D: https://datatracker.ietf.org/doc/draft-ietf-pce-applicability-actn/
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-applicability-actn-09
> 
> Please have a look and let us know if any further changes needs to be made. 
> 
> Thanks! 
> Dhruv, Young & Daniele
> 
> --
> Dhruv Dhody 
> Lead Architect
> Network Business Line
> Huawei Technologies India Pvt. Ltd.
> Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield
> Bengaluru, Karnataka - 560066 
> Tel: + 91-80-49160700 Ext 71583 II Email: dhruv.dh...@huawei.com
> 
> This e-mail and its attachments contain confidential information from HUAWEI, 
> which 
> is intended only for the person or entity whose address is listed above. Any 
> use of the 
> information contained herein in any way (including, but not limited to, total 
> or partial 
> disclosure, reproduction, or dissemination) by persons other than the 
> intended 
> recipient(s) is prohibited. If you receive this e-mail in error, please 
> notify the sender by 
> phone or email immediately and delete it!
> 
> 
>> -Original Message-
>> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
>> Sent: 25 February 2019 18:24
>> To: pce@ietf.org
>> Subject: [Pce] WG Last Call completed for draft-ietf-pce-applicability-
>> actn
>> 
>> Hi,
>> 
>> The WG last call completed without any dissent, but with only a few
>> comments of support.
>> 
>> There were some issues raised (including from Dan and me).
>> 
>> Authors:
>> Please post a revision that addresses the comments.
>> 
>> Working Group:
>> Please continue to send messages of support so that we know that this
>> draft really should be advanced.
>> 
>> Thanks,
>> Adrian
>> 
>> -Original Message-
>> From: Pce  On Behalf Of Adrian Farrel
>> Sent: 08 February 2019 11:34
>> To: pce@ietf.org
>> Subject: [Pce] WG Last Call on draft-ietf-pce-applicability-actn
>> 
>> Hi WG,
>> 
>> draft-ietf-pce-applicability-actn seems to be ready to progress towards
>> publication.
>> 
>> This email starts a two week working group last call (ends on 23rd
>> February).
>> 
>> During this time, please read the draft and make comments for improvement.
>> If you then support its publication please let us know that you have read
>> the draft and support it. If you have any concerns, please let us know and
>> propose solutions.
>> 
>> 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
> 
> ___
> 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] Replacing Jon as PCE Co-Chair

[Jeff Tantsura]

John,

Thanks for your great contribution!
Dhruv - welcome!

Regards,
Jeff

> On Jan 28, 2019, at 08:13, BRUNGARD, DEBORAH A  wrote:
> 
> 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
>  
> ___
> 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] changes in draft-sivabalan-pce-binding-label-sid-06

[Jeff Tantsura]

Dear PCE,

The authors have published updated version that should address comments 
received on the list

Summary of Changes:
- Encoding changes to the TLV
- Support for SRv6 Binding Type
- Reference to PCECC based binding SID allocation (and appendix text moved to 
the PCECC I-D)

We believe the draft is ready for wg adoption and would like to request the 
chairs to start the adoption call.
Thanks!

Cheers,
Jeff

> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jeff Tantsura
> Sent: Wednesday, November 07, 2018 10:19 AM
> To: pce@ietf.org
> Subject: [Pce] Fwd: PCE-BSID Question to the List
>
> Dear PCE,
>
> Following our presentation in Bangkok, 
> https://datatracker.ietf.org/meeting/103/materials/slides-103-pce-23-binding-segment-00.pdf
>
> The authors would like to ask the WG the following:
>
>
> (1) Do we link the Binding SID to the PCEP SR capability? Currently we
> can assign BSID for RSVP-TE LSP as well.
>
> [Zhibo]Yes, it is important, I could think of few use cases-> “domain 
> stitching”,” solving MSD limits” and “interworking b/w MPLS and SRv6 domains” 
> by PCE
>
>
> (2) Is WG happy with TE-PATH-BINDING TLV format?
>
> 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 | Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Binding Type (BT) | Binding Value |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ~ Binding Value (continued) (variable length) ~
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> [Zhibo] I prefer the length of BT field is 8 bits, and adding 24 reserved 
> bits for future features, such as flag or something else.
>
>    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  | Length    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  BT   | reserved  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ~    Binding Value (variable length)    ~
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> This encoding of BSID is similar to BGP 
> [https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2]
>  that works for both SR-MPLS and SRv6.
> When length is 8, then the binding Value is a MPLS label, when length is 20, 
> the binding value is a SRv6 SID.
>
>
> Figure 2: TE-PATH-BINDING TLV
>
> (3) Is there a use case for binding value as “index” in SRGB/SRLB?
> [Zhibo] I think there is no use case for binding value as “index” in SRLB, 
> cause BSID may not be a global label.
>
>
> Thanks!
>
> Cheers,
> Jeff
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

[Jeff Tantsura]

Yes/support

Regards,
Jeff

> On Jun 4, 2019, at 20:26, Dhruv Dhody  wrote:
> 
> Hi WG,
> 
> This email starts a working group last call for
> draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, till
> 19th June 2019.
> 
> https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/
> 
> Please indicate your support or concern for this draft.
> 
> If you are opposed to the progression of the draft, please articulate your
> concern.
> 
> If you support, please indicate that you have read the latest version and
> it is ready for publication. Further, explaining the importance of the work in
> your opinion is appreciated.
> 
> As always, review comments and nits are most welcome. Silence on the list, not
> so much :)
> 
> Thanks,
> Dhruv, Julien, & 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

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

[Jeff Tantsura]

Yes/support 

Regards,
Jeff

> On Jul 14, 2019, at 06:00, Adrian Farrel  wrote:
> 
> draft-leedhody-pce-vn

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

Re: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07

[Jeff Tantsura]

As co-author support adoption.
Preemptively - not aware of any IPR

Cheers,
Jeff
On Aug 20, 2019, 1:45 PM -0400, Dhruv Dhody , wrote:
> Hi WG,
>
> This email begins the WG adoption poll for
> draft-sivabalan-pce-binding-label-sid-07 [1].
>
> 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.
>
> One of the chairs did a pre-adoption review [2] and authors posted a new
> revision. Note that there are known implementations.
>
> This adoption poll will end on 6th September 2019.
>
> Thanks!
> Dhruv (for the chairs)
>
>
> [1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07
> [2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk
>
> ___
> 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-sivabalan-pce-binding-label-sid-07

[Jeff Tantsura]

Hi Hari,

I’m not aware of any IPR applicable.

Regards,
Jeff

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

Re: [Pce] Adrian stepping down as PCE co-chair

[Jeff Tantsura]

Thanks Adrian!

Cheers,
Jeff
On Sep 11, 2019, 1:14 PM -0700, BRUNGARD, DEBORAH A , wrote:
> Hi,
>
> As we noted earlier, Adrian stepped in to help us with the PCE document queue 
> and help bring Dhruv on as a new chair. He has done a fantastic job and Dhruv 
> and Julien are now ready to go forward.
>
> We very much appreciate his support and thank him for all his help!
>
> Deborah
>
> ___
> 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] Proposal for signaling ECMP or UCMP paths

[Jeff Tantsura]

Mike,

Thanks for the consideration.
That was exactly my point, having a number of different drafts that are short, 
concise and focused on a particular problem has always been my preference.
The use cases are different, while they don’t conflict they are also don’t 
“require” each other. It is perfectly fine for drafts to reference each other 
and outline the interdependencies, if any.

Cheers,
Jeff
On Jul 26, 2019, 5:55 AM -0400, Mike Koldychev (mkoldych) , 
wrote:
> Hi Jeff, and WG,
>
> To follow up on your comment about making these 2 separate documents: one for 
> ECMP within a single LSP and another for ECMP among different LSPs..
>
> That may be a good idea, since the mechanisms for achieving these two are 
> quite different, so they are better kept separate. Just as long as it’s 
> understood that they are not “conflicting” solutions.
>
> Thanks,
> Mike.
>
> From: Mike Koldychev (mkoldych)
> Sent: Tuesday, July 23, 2019 9:03 AM
> To: Mike Koldychev (mkoldych) ; Cyril Margaria 
> 
> Cc: pce@ietf.org
> Subject: RE: [Pce] Proposal for signaling ECMP or UCMP paths
>
> Hi,
>
> I have updated the slides based on our discussion.
>
> https://github.com/mkoldych-cisco/ietf105/blob/master/pcep_multiple_ERO.pptx
>
> We plan to discuss the issue further on Wednesday at 8:30 at the side meeting.
>
> https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings
>
> Thanks,
> Mike.
>
> From: Pce  On Behalf Of Mike Koldychev (mkoldych)
> Sent: Friday, July 19, 2019 1:03 PM
> To: Cyril Margaria 
> Cc: pce@ietf.org
> Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths
>
> Hi Cyril,
>
> Like I wrote in the slides… Solution 1 may work if you *only* do 
> PCE-initiated, because the PCC never requests anything from the PCE, it 
> simply installs whatever the PCE pushes down. Even for PCE-initiated, there 
> are some issues, such as forcing the PCE to encode all the LSP objects into 
> one message, to force them to get installed at the same time. Also you would 
> need to handle fragmentation, if you cannot fit all the LSPs into a single 
> message.
>
> Thanks,
> Mike.
>
> From: Cyril Margaria 
> Sent: Friday, July 19, 2019 12:23 PM
> To: Mike Koldychev (mkoldych) 
> Cc: pce@ietf.org
> Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths
>
> Hi Mike,
>
> One of my point is that one optimization is a peculiar case of n 
> optimization. For the particuliar case of candidate path, it can be attached 
> to a given association, each TE-LSP can have the same optimization criterias.
>
> I understand the argument for Option 2 as "I want to carry and manage my 
> constraint  (and candidate path) as one PCEP entity", the drawback is that it 
> will become complicated in case of inter-domain and OAM which are per path.
> The case for option 1 is one path, one LSP, but as you pointed out it becomes 
> complicated when there is one candidate path that desire a behavior similar 
> to  LOAD-BALANCING where the PCC ask the PCE to decide how many path are 
> needed.
>
> I think that option 1 is better in term of protocol reuse and will offer more 
> flexibility, but that depends on how to deal with the PCE-managed number of 
> paths.
>
> I will not attend the IETF meeting,
>
> Best regards,
> Cyril
>
>
>
> On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych)  
> wrote:
> > Hi Cyril,
> >
> > Thanks a lot for your feedback!
> >
> > Maybe I need to make it clear that the problem we’re trying to solve is a 
> > single optimization objective resulting in multiple ECMP/UCMP paths. This 
> > is motivated by SR-TE Policy use case, where each Candidate Path represents 
> > a single optimization objective. The Candidate Path has a set of Segment 
> > Lists that satisfy the optimization objective.
> >
> > You seem to want to solve a different problem: two or more different 
> > optimization objectives and each ECMP path is mapped to a different 
> > objective. In that case Solution 1 is absolutely necessary and it would not 
> > have any of the down-sides, because the PCC knows in advance how many 
> > optimization objectives it has and can create that many PCEP LSPs. However 
> > for our problem, Solution 1 would introduce a lot of implementation 
> > complexity and protocol overhead.
> >
> > We have a side-meeting scheduled on Wednesday at 8:30 to discuss this 
> > topic, you are welcome to attend if you want to contribute your input.
> >
> > Thanks,
> > Mike.
> >
> > From: Cyril Margaria 
> > Sent: Friday, July 19, 2019 9:37 AM
> > To: Mike Koldychev (mkoldych) 
> > Cc: pce@ietf.org
> > Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths
> >
> > Hi,
> >
> > On slide "LSP objectives and constraints": Stateless  PCE can compute set 
> > of EROs/Label switch paths using RFC6007, including multi-domain and 
> > multi-PCEs scenarios. This can be used for computing a set of EROs for SR 
> > candidate paths, one case that can apply to the candidate path and 
> > explicitly mentioned by the RFC is "Two or more end-to-end 

Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-00.txt

[Jeff Tantsura]

+1

Regards,
Jeff

> On Nov 9, 2019, at 09:53, Jonathan Hardwick 
>  wrote:
> 
> I support publication.
> Cheers
> Jon
> 
> -Original Message-
> From: Dhruv Dhody  
> Sent: 08 November 2019 16:07
> To: pce@ietf.org
> Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-00.txt
> 
> Hi WG,
> 
> As instructed by our AD, I-D has been posted with the file name change
> - draft-ietf-pce-stateful-flags-00.
> 
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/
> 
> The chairs request the WG to reaffirm that the WG supports the publication of 
> the I-D by Friday 22nd Nov. We request you to be vocal to enable us to judge 
> consensus (and justify it).
> 
> Thanks!
> Dhruv & Julien
> 
> 
>> On Thu, Nov 7, 2019 at 9:30 PM  wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Path Computation Element WG of the IETF.
>> 
>>Title   : Updated Rules for Processing Stateful PCE Request 
>> Parameters Flags
>>Author  : Adrian Farrel
>>Filename: draft-ietf-pce-stateful-flags-00.txt
>>Pages   : 6
>>Date: 2019-11-07
>> 
>> Abstract:
>>   Extensions to the Path Computation Element Communication Protocol
>>   (PCEP) to support stateful Path Computation Elements (PCEs) are
>>   defined in RFC 8231.  One of the extensions is the Stateful PCE
>>   Request Parameters (SRP) object.  That object includes a Flags field
>>   that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
>>   for tracking assigned flags.  However, RFC 8231 does not explain how
>>   an implementation should set unassigned flags in transmitted
>>   messages, nor how an implementation should process unassigned,
>>   unknown, or unsupported flags in received messages.
>> 
>>   This document updates RFC 8231 by defining the correct behaviors.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-pce-stateful-flags-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-flags-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available at 
>> tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> 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 of draft-li-pce-sr-path-segment?

[Jeff Tantsura]

I support the adoption.
Will work with the authors on some pieces that need to be clarified.

Cheers,
Jeff
On Sep 25, 2019, 9:21 AM -0700, julien.meu...@orange.com, wrote:
> Hi PCE WG,
>
> In our adoption poll queue, draft-li-pce-sr-path-segment has been there
> for a little while, after it was discussed face to face. We would now
> like you to voice your opinion on the list: do you think this I-D can be
> the foundation for a PCE WG's work item?
>
> Please send your feedback to the PCE mailing list, including any comment
> you would like to share, especially if you think the WG should not adopt
> it. This poll will end on October 9.
>
> Thanks,
>
> Dhruv & Julien
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-ietf-pce-association-policy

[Jeff Tantsura]

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

Regards,
Jeff

> On Sep 5, 2020, at 13:24, Jonathan Hardwick 
>  wrote:
> 
> I am not aware of any IPR applicable to this draft that should be disclosed
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-association-policy

[Jeff Tantsura]

Support as co-author

Cheers,
Jeff

> On Sep 4, 2020, at 07:13, Dhruv Dhody  wrote:
> 
> Hi WG,
> 
> This email starts a working group last call for
> draft-ietf-pce-association-policy [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 21st September 2020.
> 
> Thanks,
> Dhruv & Julien
> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/

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

Re: [Pce] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

[Jeff Tantsura]

Yes/support

Cheers,
Jeff

>
> Hi WG,
>
> This email begins the WG adoption poll for
> draft-barth-pce-segment-routing-policy-cp-06.
>
> https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/06/
>
> 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.
>
> This adoption poll will end on 22nd June 2020.
>
> Thanks!
> Dhruv & 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] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04

[Jeff Tantsura]

I support the adoption given points rased by Dhruv are addressed ( post 
adoption in fine)

Cheers,
Jeff
On Jan 8, 2021, 1:32 AM -0800, Dhruv Dhody , wrote:
> Hi WG, Authors,
>
> Speaking as a WG participant...
>
> I find the functionality described in this I-D to be very useful. But,
> I have one concern that I would like to be addressed before adoption
> or at least get an agreement on (to be handled post-adoption).
>
> I am not in favor of how the PST is being used in the I-D. The PST is used -
> - between PCEs to indicate inter-domain TE processing
> - between PCE and the head-end (2 PST for RSVP-TE & SR each, but for
> inter-domain i.e also allocate and report stitching label)
>
> We basically need a mechanism to request allocation and reporting of
> stitching labels. I strongly suggest using a flag and/or a new TLV, I
> find the use of PST for this inappropriate.
>
> A weird side-effect of the current proposal is that every time we have
> a new PST defined (PCECC is post-WGLC), we would need another one for
> inter-domain.
>
> Moreover, wouldn't it be better if this I-D is independent of the
> per-domain path setup type? Section 6.3 allows for mixed technologies
> and the protocol procedures between cooperating PCEs can be defined
> such that they are independent of the per-domain path setup type to
> allow for any current or future path setup types. I see no reason to
> differentiate between RSVP-TE and SR (section 6.2 is all about
> forwarding on border nodes, and not about PCEP).
>
> I discussed this with the authors earlier, where we basically pushed
> the can down the road, I hope we can resolve this quickly now :)
>
> Thanks!
> Dhruv
> (As a WG participant)
>
> On Fri, Dec 18, 2020 at 6:23 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-interdomain-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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-ietf-pce-binding-label-sid-07

[Jeff Tantsura]

Hi Hari,

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

Regards,
Jeff

> On Mar 18, 2021, at 10:10, Hariharan Ananthakrishnan  wrote:
> 
> 
> Hi Authors,
> 
> In preparation for WG 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 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] [**EXTERNAL**] WG Adoption of draft-koldychev-pce-multipath-05

[Jeff Tantsura]

Yes/support 

Regards,
Jeff

> On Apr 14, 2021, at 09:00, Stone, Andrew (Nokia - CA/Ottawa) 
>  wrote:
> 
> 
> Hi WG
>  
> +1. Support adoption. Provides a nice and simple way to encode multiple 
> paths, whether they be weighted or for backup purposes. Fills needed gaps in 
> the Unicast SR Policy and P2MP SR Policy documents.
>  
> Thanks
> Andrew
>  
> From: Pce  on behalf of "Samuel Sidor (ssidor)" 
> 
> Date: Wednesday, April 14, 2021 at 11:20 AM
> To: Dhruv Dhody 
> Cc: "pce@ietf.org" , "Yadav, Bhupendra" 
> , "draft-koldychev-pce-multip...@ietf.org" 
> 
> Subject: Re: [Pce] [**EXTERNAL**] WG Adoption of 
> draft-koldychev-pce-multipath-05
>  
> Hi WG,
>  
> I support adoption of this draft.
>  
> Regards,
> Samuel
>  
> From: Pce  On Behalf Of Yadav, Bhupendra
> Sent: Wednesday, April 14, 2021 5:14 PM
> To: Dhruv Dhody ; pce@ietf.org
> Cc: draft-koldychev-pce-multip...@ietf.org
> Subject: Re: [Pce] [**EXTERNAL**] WG Adoption of 
> draft-koldychev-pce-multipath-05
>  
> Hi WG,
>  
> I support adoption of this draft by PCE WG. This draft provides a clean and 
> logical mechanism for conveying multiple paths peers.
> I am willing to work on this draft.
>  
> Thanks,
> Bhupendra
> From: Dhruv Dhody 
> Sent: April 14, 2021 10:52 AM
> To: pce@ietf.org 
> Cc: draft-koldychev-pce-multip...@ietf.org 
> 
> Subject: [**EXTERNAL**] WG Adoption of draft-koldychev-pce-multipath-05
>  
> Hi WG,
> 
> This email begins the WG adoption poll for draft-koldychev-pce-multipath-05.
> 
> https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05 
> [datatracker.ietf.org]
> 
> 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. 
>  
> Please respond by Wednesday 28th April.
> 
> Thanks!
> Dhruv & 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] [PCE]:New Version Notification for draft-peng-pce-entropy-label-position-05.txt

[Jeff Tantsura]

Hi,

It is the job of ingress router to impose the SID(label) stack that would 
include one or more pairs of ELI/EL. This is always a subject to MSD 
limitations (per platform/per LC if applicable). 
The draft is not discussing implications of these limitations , which I find 
rather unfortunate.

Regards,
Jeff

> On Feb 20, 2021, at 00:15, xiong.q...@zte.com.cn wrote:
> 
> 
> Dear Dhruv,Stephane,Zhenbin Li,Tarek and WG,
> 
> 
> 
> I just submitted a new version of the 
> draft-peng-pce-entropy-label-position-05. This draft has been presented in 
> IETF 106 and 107. Many thanks for your comments and discussions. 
> 
> 
> 
> First, I think we have the consensus that in case of inter-domain scenario, 
> PCE would be useful for computing both SR path and the placement of entropy 
> labels. We should propose a set of extensions for PCEP.
> 
> 
> 
> Second, I fully agree with that the ingress MUST support the capability of  
> inserting multiple ELI/ELs and it needs to advertise the capability to PCE. 
> So I think we should add the capability in OPEN message from PCC to PCE. In 
> the current version, we define the E bit for a PCC  to  indicate that it 
> supports the capability of inserting multiple ELI/EL pairs and and supports 
> the results of SR path with ELP from PCE. What is your suggestion? If the E 
> bit is enough? Or should we define the BGP/IGP extension?
> 
> 
> 
> Finally, thanks to Zhenbin, I need to clarify that the ELI/EL pairs are 
> calculated for a specific traffic flow but the placement of the ELI/EL pairs 
> are calculated for a SR-path. In our draft, we propose the PCEs perform 
> computation of SR-path with the the placement of the ELI/EL pairs and the 
> value of ELI/EL pairs are calculated  at the ingress.
> 
> 
> 
> I look forward and appreciate any comment and suggestion from you.
> 
> 
> 
> Thanks,
> 
> Quan
> 
> 
> 
> 
> 
> 主 题 ：New Version Notification for draft-peng-pce-entropy-label-position-05.txt
> 
> A new version of I-D, draft-peng-pce-entropy-label-position-05.txt
> has been successfully submitted by Quan Xiong and posted to the
> IETF repository.
> 
> Name:draft-peng-pce-entropy-label-position
> Revision:05
> Title:PCEP Extension for SR-MPLS Entropy Label Position
> Document date:2021-02-19
> Group:Individual Submission
> Pages:9
> URL:
> https://www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-05.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-peng-pce-entropy-label-position
> Htmlized:   
> https://tools.ietf.org/html/draft-peng-pce-entropy-label-position-05
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-peng-pce-entropy-label-position-05
> 
> Abstract:
>This document proposes a set of extensions for PCEP to configure the
>entropy label position for SR-MPLS networks.
> 
>   
>  
> 
> 
> 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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[Jeff Tantsura]

+1

Regards,
Jeff

> On Feb 22, 2021, at 14:13, Stone, Andrew (Nokia - CA/Ottawa) 
>  wrote:
> 
> +1 thanks Julien, also support the document. 
> 
> Did not recognize that binding label and path segment we're requesting bits 
> as well. Seems like this draft is pre-empting the inevitable exhaustion at a 
> good time. 
> 
> Thanks
> Andrew
> 
> 
> On 2021-02-19, 11:05 AM, "Pce on behalf of Adrian Farrel" 
>  wrote:
> 
>Ah, that's useful. Thanks Julien.
> 
>Makes this work more pressing.
> 
>Informative references to those two drafts would help focus the reviewer's 
> mind and might be handy when this draft overtakes those other two documents 
> and goes to the IESG.
> 
>Cheers,
>Adrian
> 
>-Original Message-
>From: julien.meu...@orange.com  
>Sent: 19 February 2021 14:38
>To: adr...@olddog.co.uk
>Cc: pce@ietf.org
>Subject: Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03
> 
>Hi Adrian,
> 
>Thank you for your feedback.
> 
>If evidence is needed, how about binding label?
>
> https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-06#section-11.2
>Note it's also reused in
>https://tools.ietf.org/html/draft-ietf-pce-sr-path-segment-03#section-4.2
> 
>Have a nice week-end,
> 
>Julien
> 
> 
>>On 18/02/2021 16:57, Adrian Farrel wrote:
>> Thanks to the authors for cleaning this up a lot since last time.
>> 
>> I don't object to adoption. Would be nice to have evidence of someone
>> needing a bit now, but by the time this becomes an RFC it is reasonably
>> possible.
>> 
>> Adrian
>> 
>> -Original Message-
>> From: Pce  On Behalf Of Dhruv Dhody
>> Sent: 01 February 2021 17:48
>> 
>> Hi WG,
>> 
>> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>> 
>> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03
>> 
>> This is a small draft that extends the flags in the LSP Objects by
>> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
>> sub-registry "LSP Object Flag Field" is almost fully assigned.
>> 
>> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field
>> 
>> 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.
>> 
>> Please respond by Monday 15th Feb.
>> 
>> Thanks!
>> Dhruv & 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
>> 
> 
> 
>
> _
> 
>Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
>This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
>Thank you.
> 
>___
>Pce mailing list
>Pce@ietf.org
>https://www.ietf.org/mailman/listinfo/pce
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

Re: [Pce] Adoption of draft-dhody-pce-stateful-pce-optional

[Jeff Tantsura]

Yes/support

Cheers,
Jeff

> On Sep 21, 2021, at 07:01, julien.meu...@orange.com wrote:
> 
> Hi all,
> 
> This e-mail starts an adoption poll for 
> draft-dhody-pce-stateful-pce-optional-08 [1]. Do you consider this I-D is 
> ready to become a PCE WG item?
> 
> Please respond to the PCE list, including rationale if you believe the WG 
> should not adopt it.
> 
> Thanks,
> 
> Dhruv & Julien
> 
> 
> [1] 
> https://datatracker.ietf.org/doc/html/draft-dhody-pce-stateful-pce-optional-08
> 
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

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

[Jeff Tantsura]

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

Cheers,
Jeff

> On Sep 26, 2022, at 20:19, Hariharan Ananthakrishnan  wrote:
> 
> I am not aware of any IPR applicable to this draft that should be disclosed 
> in accordance with IETF IPR rules.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce