Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

[Dhruv Dhody]

Hi Hooman,

On Fri, Feb 12, 2021 at 5:36 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
hooman.bidg...@nokia.com> wrote:

> [Dhruv]: I feel there is some misunderstanding here. The PCECC extensions
> defined a new object called CCI, with different object-types to be defined
> for various use-cases. There is common handling for all such instructions
> and it is defined once and can be reused across multiple use cases. I
> understand that you want to use the ERO object with multi-path, and that
> *is* fine, you could in fact easily define the RBNF in such a way that both
> CCI and ERO are included for the new CCI object type for SR-P2MP.
>
> Hi Dhruv
>
> I am not sure if I understand are you suggesting we include both CCI and
> ERO as an option and vendor chooses? What benefit does this have? How would
> this improve the interop?
>
> No, I did not say "or", it is not a choice!

In PCEP when we communicate with the head-end we use Candidate Path as the unit
of signaling (with Policy as an association). For programming instructions
(and not paths) we use CCI Object. New CCI Object-type for each use
case can be defined.

I think your proposal to program the replication and leaf nodes as (section
3.4.2) -

   
   []
   
   []
   as described in [draft-sivabalan-pce-binding-label-sid]
   []
   as per [draft-koldychev-pce-multipath]

* RBNF is not correct, but I get the idea! I.e. you are signaling this as a
path on the branches and leaves :(

=

What I suggested is that for programming the branch and leaf node, we
should use CCI as a unit of signaling and you can include the ERO and
PATH-ATTRIB along with the CCI. Note this is a new CCI Object-type and RBNF
can be updated for it -

   
   
   [] <- not included for shared case
<- you can carry the replication-sid as TE-binding as a TLV here
   [()...] <- this is a list

To Recap
- you needed ERO and PATH-ATTRIB and you get that here!
- the unit of signaling is a programming instruction and not a Path for the
above case!
- aligns with other use cases in PCEP

Hope I am able to explain myself clearly and this helps!

Thanks!
Dhruv



> Thanks
> Hooman
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Thursday, February 11, 2021 5:01 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) 
> Cc: pce-cha...@ietf.org; pce@ietf.org
> Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi Hooman,
>
> Please see inline...
>
> On Tue, Feb 9, 2021 at 8:36 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com> wrote:
> >
> > Hi Dhruv
> >
> > Much appreciate your reply, Inline
> >
> > Thanks
> > Hooman
> >
> >
> > -Original Message-
> > From: Dhruv Dhody 
> > Sent: Tuesday, February 9, 2021 5:28 AM
> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) 
> > Cc: pce-cha...@ietf.org; pce@ietf.org
> > Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
> >
> > Hi Hooman,
> >
> > Apologies! Missed replying to this email...
> >
> > On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidg...@nokia.com> wrote:
> > >
> > > Dear Chairs
> > >
> > >
> > >
> > > Looking at the wiki page there was a comment on the sr-p2mp-policy
> draft.
> > >
> > >
> > >
> > > draft-hsd-pce-sr-p2mp-policy
> > >
> > > 109; More work is needed - align to PCECC, text needs to aligned to
> > > the PCE WG style
> > >
> > >
> > >
> > > The authors took an action to setup a meeting and discuss the
> alignment with PCECC farther. The final outcome of this meeting was
> unanimous agreement, by all the authors/vendors on the draft, to go forward
> with ERO object.
> > >
> > >
> >
> > As an individual I-D, it is up to the co-authors to decide the content
> of the I-D.
> >
> > The comment (and earlier discussions) was to make sure we maintain
> consistency across all our documents that we produce. RFC 8283 describes
> the PCECC architecture, where the PCE needs to interact with not only the
> head-end routers (the usual stateful/stateless PCE case) but also with the
> egress and the internal P routers. The WG has just sent the first PCECC
> extension for MPLS label allocation along the path to the IESG. For other
> use cases such as SR/SRv6 SID allocation as well as for the branch node in
> the P2MP LSP and Native-IP, all are under the PCECC umbrella. So far all
> use cases where the PCE needs to interact with other nodes beyond the
> ingress and provide instructions to them are using PCECC architecture.
> >
> > So when the PCE is interacting with the head end for SR P2MP Policy, it
> can use the usual stateful PCE extensions but when the PCE is interacting
> with the branch nodes and leaf nodes for replication segment, we strongly
> feel it should be described under the PCECC architecture. So you could use
> the ERO object for encoding the full P2MP path (and SR P2MP Policy) when
> interacting with the root node.
> > But when interacting with other nodes, use the PCECC technique i.e. a
> new CCI object type (which could be used with the ERO if

Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

[Bidgoli, Hooman (Nokia - CA/Ottawa)]

[Dhruv]: I feel there is some misunderstanding here. The PCECC extensions 
defined a new object called CCI, with different object-types to be defined for 
various use-cases. There is common handling for all such instructions and it is 
defined once and can be reused across multiple use cases. I understand that you 
want to use the ERO object with multi-path, and that *is* fine, you could in 
fact easily define the RBNF in such a way that both CCI and ERO are included 
for the new CCI object type for SR-P2MP.

Hi Dhruv

I am not sure if I understand are you suggesting we include both CCI and ERO as 
an option and vendor chooses? What benefit does this have? How would this 
improve the interop?

Thanks
Hooman

-Original Message-
From: Dhruv Dhody  
Sent: Thursday, February 11, 2021 5:01 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) 
Cc: pce-cha...@ietf.org; pce@ietf.org
Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Please see inline...

On Tue, Feb 9, 2021 at 8:36 PM Bidgoli, Hooman (Nokia - CA/Ottawa) 
 wrote:
>
> Hi Dhruv
>
> Much appreciate your reply, Inline
>
> Thanks
> Hooman
>
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Tuesday, February 9, 2021 5:28 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) 
> Cc: pce-cha...@ietf.org; pce@ietf.org
> Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi Hooman,
>
> Apologies! Missed replying to this email...
>
> On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa) 
>  wrote:
> >
> > Dear Chairs
> >
> >
> >
> > Looking at the wiki page there was a comment on the sr-p2mp-policy draft.
> >
> >
> >
> > draft-hsd-pce-sr-p2mp-policy
> >
> > 109; More work is needed - align to PCECC, text needs to aligned to 
> > the PCE WG style
> >
> >
> >
> > The authors took an action to setup a meeting and discuss the alignment 
> > with PCECC farther. The final outcome of this meeting was unanimous 
> > agreement, by all the authors/vendors on the draft, to go forward with ERO 
> > object.
> >
> >
>
> As an individual I-D, it is up to the co-authors to decide the content of the 
> I-D.
>
> The comment (and earlier discussions) was to make sure we maintain 
> consistency across all our documents that we produce. RFC 8283 describes the 
> PCECC architecture, where the PCE needs to interact with not only the 
> head-end routers (the usual stateful/stateless PCE case) but also with the 
> egress and the internal P routers. The WG has just sent the first PCECC 
> extension for MPLS label allocation along the path to the IESG. For other use 
> cases such as SR/SRv6 SID allocation as well as for the branch node in the 
> P2MP LSP and Native-IP, all are under the PCECC umbrella. So far all use 
> cases where the PCE needs to interact with other nodes beyond the ingress and 
> provide instructions to them are using PCECC architecture.
>
> So when the PCE is interacting with the head end for SR P2MP Policy, it can 
> use the usual stateful PCE extensions but when the PCE is interacting with 
> the branch nodes and leaf nodes for replication segment, we strongly feel it 
> should be described under the PCECC architecture. So you could use the ERO 
> object for encoding the full P2MP path (and SR P2MP Policy) when interacting 
> with the root node.
> But when interacting with other nodes, use the PCECC technique i.e. a new CCI 
> object type (which could be used with the ERO if needed). This would help you 
> to not reinvent things as well as maintain consistency.
> To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5 only and 
> not the whole document. If you still disagree please list the technical 
> reason why so that the WG can evaluate them.
>
> HB> As I am sure you do appreciate there are many ways to skin the cat. 
> TreeSID can be connected via unicast SR path and not every node needs to be 
> programmed. In addition as explained the PCECC did not provide the with 
> flexibility to configure backup/fast reroute paths and the current methods 
> does provide that capability.
> Again as mentioned we looked at PCECC very hard and tried to implement 
> treeSID via this method but there were major short comings for backup and FRR 
> paths.
> There are multiple implementation in the field that is using the ERO object 
> for treeSID with success.
> Are the chairs suggesting that the working group is only dictating PCECC and 
> is not open to any other option but PCECC for the purpose of programming the 
> PCC and multicast?
> We have been asking for adaptation since 3 IETF ago and we keep getting 
> pushback because our implementation does not follow the PCECC, why is PCECC 
> the only choice on the table? Why isn't the working group open to other 
> options to solve the multicast requirements? Given the fact that the ERO has 
> been implemented and is in the field and in multiple providers labs being 
> tested with successful outcome, I think the WG should have a open view to 
> this impl

Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

[julien.meuric]

Hi Hooman,

Please keep in mind that adoption isn't a prerequisite to start getting
input. You've already started to get some. Technical discussion on the
list is part of the normal working process and it helps the chairs to
gauge WG consensus.

Note the adoption queue on the wiki page. If you want to progress your
work, please consider both actions:
- helping flushing the queues by sharing your feedback on the mailing
list, especially during adoption polls and WG last calls;
- socializing your I-D by addressing received comments: that doesn't
mean including every single suggestion, but in case the authors disagree
with a point made, the WG deserves some elaboration.

Thanks,

Julien


On 09/02/2021 16:06, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:


> HB> sure this is cosmetics and we will follow the WG suggestion, that said 
> this should not stop the adaptation call. The sooner we have adaptation call 
> the sooner we can have input.
>
> HB> to close, as you mentioned some of the co-authors have vast experience in 
> PCE WG and the same co-authors have agreed and recommended ERO 
> implementation. As such I ask the chairs for adaptation call again ASAP. We 
> will fix the cosmetics to be inline with WG recommendations asap.


_

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] Secdir telechat review of draft-ietf-pce-pcep-extension-for-pce-controller-12

[Yaron Sheffer via Datatracker]

Reviewer: Yaron Sheffer
Review result: Ready

I reviewed the latest version and I'm OK with the changes. I'd like to thank
the authors for their prompt response.


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

Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

[Dhruv Dhody]

Hi Hooman,

Please see inline...

On Tue, Feb 9, 2021 at 8:36 PM Bidgoli, Hooman (Nokia - CA/Ottawa)
 wrote:
>
> Hi Dhruv
>
> Much appreciate your reply, Inline
>
> Thanks
> Hooman
>
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Tuesday, February 9, 2021 5:28 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) 
> Cc: pce-cha...@ietf.org; pce@ietf.org
> Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi Hooman,
>
> Apologies! Missed replying to this email...
>
> On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa) 
>  wrote:
> >
> > Dear Chairs
> >
> >
> >
> > Looking at the wiki page there was a comment on the sr-p2mp-policy draft.
> >
> >
> >
> > draft-hsd-pce-sr-p2mp-policy
> >
> > 109; More work is needed - align to PCECC, text needs to aligned to
> > the PCE WG style
> >
> >
> >
> > The authors took an action to setup a meeting and discuss the alignment 
> > with PCECC farther. The final outcome of this meeting was unanimous 
> > agreement, by all the authors/vendors on the draft, to go forward with ERO 
> > object.
> >
> >
>
> As an individual I-D, it is up to the co-authors to decide the content of the 
> I-D.
>
> The comment (and earlier discussions) was to make sure we maintain 
> consistency across all our documents that we produce. RFC 8283 describes the 
> PCECC architecture, where the PCE needs to interact with not only the 
> head-end routers (the usual stateful/stateless PCE case) but also with the 
> egress and the internal P routers. The WG has just sent the first PCECC 
> extension for MPLS label allocation along the path to the IESG. For other use 
> cases such as SR/SRv6 SID allocation as well as for the branch node in the 
> P2MP LSP and Native-IP, all are under the PCECC umbrella. So far all use 
> cases where the PCE needs to interact with other nodes beyond the ingress and 
> provide instructions to them are using PCECC architecture.
>
> So when the PCE is interacting with the head end for SR P2MP Policy, it can 
> use the usual stateful PCE extensions but when the PCE is interacting with 
> the branch nodes and leaf nodes for replication segment, we strongly feel it 
> should be described under the PCECC architecture. So you could use the ERO 
> object for encoding the full P2MP path (and SR P2MP Policy) when interacting 
> with the root node.
> But when interacting with other nodes, use the PCECC technique i.e. a new CCI 
> object type (which could be used with the ERO if needed). This would help you 
> to not reinvent things as well as maintain consistency.
> To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5 only and 
> not the whole document. If you still disagree please list the technical 
> reason why so that the WG can evaluate them.
>
> HB> As I am sure you do appreciate there are many ways to skin the cat. 
> TreeSID can be connected via unicast SR path and not every node needs to be 
> programmed. In addition as explained the PCECC did not provide the with 
> flexibility to configure backup/fast reroute paths and the current methods 
> does provide that capability.
> Again as mentioned we looked at PCECC very hard and tried to implement 
> treeSID via this method but there were major short comings for backup and FRR 
> paths.
> There are multiple implementation in the field that is using the ERO object 
> for treeSID with success.
> Are the chairs suggesting that the working group is only dictating PCECC and 
> is not open to any other option but PCECC for the purpose of programming the 
> PCC and multicast?
> We have been asking for adaptation since 3 IETF ago and we keep getting 
> pushback because our implementation does not follow the PCECC, why is PCECC 
> the only choice on the table? Why isn't the working group open to other 
> options to solve the multicast requirements? Given the fact that the ERO has 
> been implemented and is in the field and in multiple providers labs being 
> tested with successful outcome, I think the WG should have a open view to 
> this implantation. Especially when multiple vendors and providers (Cisco, 
> Juniper, Nokia, Ciena, Bell Canada) to name a few have agreed to this 
> implementation.
>
>

[Dhruv]: I feel there is some misunderstanding here. The PCECC
extensions defined a new object called CCI, with different
object-types to be defined for various use-cases. There is common
handling for all such instructions and it is defined once and can be
reused across multiple use cases. I understand that you want to use
the ERO object with multi-path, and that *is* fine, you could in fact
easily define the RBNF in such a way that both CCI and ERO are
included for the new CCI object type for SR-P2MP.

Thanks!
Dhruv

> >
> > The authors feel ERO object in addition to draft-koldychev-pce-multipath-04 
> > - PCEP Extensions for Signaling Multipath Information (ietf.org) for backup 
> > paths is the easiest and the most efficient way to address the programming 
> > of a replication segm

Re: [Pce] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11

[Pengshuping (Peng Shuping)]

Hi Gyan, 

Many thanks for your review. Please find my responses inline below. 

I have also uploaded the new version of this draft according to your reviews 
and suggestions. . 

https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12
 
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12

Please let us know if there is any further comments. 

Thank you!

> -Original Message-
> From: Gyan Mishra via Datatracker [mailto:nore...@ietf.org]
> Sent: Thursday, February 11, 2021 7:03 AM
> To: gen-...@ietf.org
> Cc: draft-ietf-pce-pcep-extension-for-pce-controller@ietf.org;
> last-c...@ietf.org; pce@ietf.org
> Subject: Genart last call review of
> draft-ietf-pce-pcep-extension-for-pce-controller-11
> 
> Reviewer: Gyan Mishra
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-pce-pcep-extension-for-pce-controller-??
> Reviewer: Gyan Mishra
> Review Date: 2021-02-10
> IETF LC End Date: 2021-02-08
> IESG Telechat date: 2021-02-25
> 
> Summary:
> This document is very well written and describes a new PCEP protocol
> extension for using PCE as a centralized controller PCECC for provisioning
> using its own discrete label space for all or discrete parts static LSP ERO
> path.
> 
> Major issues:
> None
> 
> Minor issues:
> 
> For stateful PCE how do you prevent label collisions when both the PCE is
> provisioning using its own label space and the routers also are using their
> own label space as well and have a mix of both.  After the label download
> and sync at each router hop PCE PCC session their maybe some nodes that
> use the router label space  and other nodes using PCE label space.
> 

This is covered in Section 3, I have added text to clarify further -

   As per Section 3.1.2. of [RFC8283], the PCE-based controller will
   take responsibility for managing some part of the MPLS label space
   for each of the routers that it controls, and may take wider
   responsibility for partitioning the label space for each router and
   allocating different parts for different uses.  The PCC MUST NOT make
   allocations from the label space set aside for the PCE to avoid
   overlap and collisions of label allocations.


> It would seem more complicated to have a mix of having both PCE managed
> label space and non PCE managed label space and for this draft since it’s
> about provisioning static LSP using PCE discrete label space I think it would
> make more sense to have entire LSP to be provisioned using PCE label space
> to prevent label collisions.  This caveat I think should be added to the
> considerations section as well.   

OK, I have added -

   It is RECOMMENDED that
   PCE makes allocations (from the label space set aside for the PCE)
   for all nodes along the path.


> I did not see it mentioned but I think it’s
> also worthwhile mentioning what is the advantage of using this extension
> where the PCE uses its own label space.  Also list the disadvantages as well
> so the operator had a clear picture of reasons to use this extension and
> maybe reasons to not use.  It maybe also worthwhile to mention use cases
> where it makes sense to use this extension and others where it is not.


I have added the following text, which includes the correct references -

   [RFC8283] examines the motivations and applicability for PCECC and
   use of PCEP as an SBI.  Section 3.1.2. of [RFC8283] highlights the
   use of PCECC for label allocation along the static LSPs and it
   simplifies the processing of a distributed control plane by blending
   it with elements of SDN and without necessarily completely replacing
   it.  This allows the operator to introduce the advantages of SDN
   (such as programmability) into the network.  Further Section 3.3. of
   [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where
   the PCECC technique could be useful.  Section 4 of [RFC8283] also
   describe the implications on the protocol when used as an SDN SBI.
   The operator needs to evaluate the advantages offered by PCECC
   against the operational and scalability needs of the PCECC.


> 
> In section 9 I agree it’s a good idea to have mutually authentication and
> encrypted sessions for all PCE PCC sessions to prevent malicious PCE using
> this extension.
> 
> Nits/editorial comments:
> The abstract states the following in the last sentence which I think should
> better describe the goal and purpose of the draft.
> 
> “ This document specifies the procedures and PCEP extensions for using
> the PCE as the central controller.”
> 
> I would say use of PCE as a centralized controller for provisioning R

[Pce] I-D Action: draft-ietf-pce-pcep-extension-for-pce-controller-12.txt

[internet-drafts]

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

Title   : PCEP Procedures and Protocol Extensions for Using PCE 
as a Central Controller (PCECC) of LSPs
Authors : Zhenbin Li
  Shuping Peng
  Mahendra Singh Negi
  Quintin Zhao
  Chao Zhou
Filename: 
draft-ietf-pce-pcep-extension-for-pce-controller-12.txt
Pages   : 40
Date: 2021-02-11

Abstract:
   The Path Computation Element (PCE) is a core component of Software-
   Defined Networking (SDN) systems.  It can compute optimal paths for
   traffic across a network and can also update the paths to reflect
   changes in the network or traffic demands.

   PCE was developed to derive paths for MPLS Label Switched Paths
   (LSPs), which are supplied to the head end of the LSP using the Path
   Computation Element Communication Protocol (PCEP).  But SDN has a
   broader applicability than signaled MPLS and GMPLS traffic-engineered
   (TE) networks, and the PCE may be used to determine paths in a range
   of use cases.  PCEP has been proposed as a control protocol for use
   in these environments to allow the PCE to be fully enabled as a
   central controller.

   A PCE-based Central Controller (PCECC) can simplify the processing of
   a distributed control plane by blending it with elements of SDN and
   without necessarily completely replacing it.  Thus, the LSP can be
   calculated/set up/initiated and the label forwarding entries can also
   be downloaded through a centralized PCE server to each network device
   along the path, while leveraging the existing PCE technologies as
   much as possible.

   This document specifies the procedures and PCEP extensions for using
   the PCE as the central controller for provisioning labels along the
   path of the static LSP.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller-12
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12


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