Re: [Pce] [E] IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

[Jalil, Luay]

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

Thanks,
*Luay*


On Fri, Dec 1, 2023 at 4:41 AM Dhruv Dhody  wrote:

> Hi Authors,
>
>
>
> In preparation for WG adoption on this draft, we'd like all authors 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,
>
> Dhruv
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] WG Review: Path Computation Element (pce)

[The IESG]

The Path Computation Element (pce) WG in the Routing Area of the IETF is
undergoing rechartering. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list
(i...@ietf.org) by 2023-12-11.

Path Computation Element (pce)
---
Current status: Active WG

Chairs:
  Julien Meuric 
  Dhruv Dhody 

Secretaries:
  Andrew Stone 

Assigned Area Director:
  John Scudder 

Routing Area Directors:
  John Scudder 
  Jim Guichard 
  Andrew Alston 

Mailing list:
  Address: pce@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/pce
  Archive: https://mailarchive.ietf.org/arch/browse/pce/

Group page: https://datatracker.ietf.org/group/pce/

Charter: https://datatracker.ietf.org/doc/charter-ietf-pce/

The PCE Working Group is chartered to specify the required protocols
so as to enable a Path Computation Element (PCE)-based architecture
for the computation of paths for MPLS and GMPLS Point to Point and
Point to Multi-point Traffic Engineered LSPs. Further, the PCE WG also
handles protocol extensions for new path setup types of Segment
Routing (SR), BIER, and Detnet.

In this architecture path computation does not necessarily occur on
the head-end (ingress) LSR, but on some other path computation entity
that may not be physically located on each head-end LSR. The TEAS
Working Group is responsible for defining and extending architectures
for Traffic Engineering (TE) and it is expected that the PCE and TEAS
WGs will work closely together on elements of TE architectures that
utilize PCE.

The PCE WG works on the application of this model within a single
domain or within a group of domains (where a domain is a layer, IGP
area, or Autonomous System with limited visibility from the head-end
LSR). At this time, applying this model to large groups of domains
such as the Internet is not thought to be possible, and the PCE WG
will not spend energy on that topic.

The WG specifies the PCE communication Protocol (PCEP) and needed
extensions for communication between Path Computation Clients (PCCs)
and PCEs, and between cooperating PCEs. Security mechanisms such as
authentication and confidentiality are included.

The WG works on the mechanisms for inter-domain as well as multi-layer
path computation and PCEP extensions for communication between several
domains or network layers.

The WG defines the required PCEP extensions for Wavelength Switched
Optical Networks (WSON) and Flexible Grid while keeping consistency
with the GMPLS protocols specified in the CCAMP and TEAS WGs.

Work Items:

- PCEP extensions to support MPLS and GMPLS Traffic Engineered LSP
  path computation models involving PCEs. This includes the case of
  computing the paths of intra- and inter-domain TE LSPs. Such path
  computation includes the generation of primary, protection, and
  recovery paths, as well as computations for (local/global)
  reoptimization and load balancing. Both intra- and inter-domain
  applications are covered.

- In cooperation with the TEAS Working Group, development of PCE-
  based architectures for Traffic Engineering including PCE as a
  Central Controller (PCECC) and Centralized Control Dynamic Routing
  (CCDR). The PCEP extensions are developed in the PCE Working Group.

- In cooperation with protocol-specific Working Groups (e.g., MPLS,
  CCAMP), development of LSP signaling (RSVP-TE) extensions required
  to support PCE-based path computation models.

- Specification of PCEP extensions for expressing path computation
  requests and responses in the various GMPLS-controlled networks,
  including WSON and Flexible Grid.

- Definition of PCEP extensions for path computation in multi-layer
  and inter-domain networks.

- Definition of the PCEP extensions used by a stateful PCE for
  recommending a new path for an existing or new LSP to the PCC/PCE.
  Further protocol extensions must cover the case where the receiving
  PCC/PCE chooses not to follow the recommendation. The PCEP
  extensions for state synchronization are also in scope.

- Definition of the PCEP extensions for SR-MPLS and SRv6 paths as per
  the SR Policy architecture in cooperation with SPRING Working Group.

- Definition of the PCEP extensions for new path setup types (such as
  BIER and DETNET) in close cooperation with the respective Working
  Groups.

Milestones:

  Nov 2023 - Submit PCEP YANG Model as a Proposed Standard

  Nov 2023 - Submit PCEP Native-IP extensions as a Proposed Standard

  Mar 2024 - Submit PCEP extensions for SR Policy as Proposed Standard

  Mar 2024 - Submit PCEP extensions for Multipath as Proposed Standard

  Dec 2024 - Submit Enhancements to Stateful PCE

  Mar 2025 - Evaluate WG progress, recharter or close



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

Re: [Pce] IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

[Andrew Stone (Nokia)]

Hi PCE WG

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

Thanks
Andrew

From: Dhruv Dhody 
Date: Friday, December 1, 2023 at 5:41 AM
To: "Samuel Sidor (ssidor)" , "praveen.maheshw...@airtel.com" 
, "Andrew Stone (Nokia)" 
, "luay.ja...@verizon.com" , 
"Pengshuping (Peng Shuping)" 
Cc: "pce@ietf.org" 
Subject: IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi Authors,

In preparation for WG adoption on this draft, we'd like all authors 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,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Fwd: [IANA #1290605] Early Code Point Allocation for draft-ietf-pce-sr-bidir-path

[Dhruv Dhody]

Hi,

This early allocation for draft-ietf-pce-sr-bidir-path has been completed!

Thanks!
Dhruv & Julien

-- Forwarded message -
From: Amanda Baber via RT 
Date: Fri, Dec 1, 2023 at 3:03 AM
Subject: [IANA #1290605] Early Code Point Allocation for
draft-ietf-pce-sr-bidir-path
To: 
Cc: , , <
xiong.q...@zte.com.cn>, , , <
c...@huawei.com>, , ,
, , 


Hi all,

We've made the following early allocation in the ASSOCIATION Type Field
registry:

Type: 8
Name: Double-Sided Bidirectional with Reverse LSP Association (TEMPORARY -
registered 2023-11-30, expires 2024-11-30)
Reference: [draft-ietf-pce-sr-bidir-path-12]

Please see
https://www.iana.org/assignments/pcep

If the document hasn't been approved for publication by October, we'll
contact the chairs and AD about approving an extension.

Also, authors: could you make the following terminology change in the IANA
Considerations section?

OLD: the "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path
Computation Element Protocol (PCEP) Numbers" registry

NEW: the "ASSOCIATION Type Field" registry [RFC8697] within the "Path
Computation Element Protocol (PCEP) Numbers" registry group

thanks,

Amanda Baber
IANA Operations Manager

On Thu Nov 30 14:16:49 2023, julien.meu...@orange.com wrote:
> Hi IANA,
>
> Following the procedure for early allocation as per RFC 7120, we would
> like to request early allocation for the following code point defined
> in
> https://www.ietf.org/archive/id/draft-ietf-pce-sr-bidir-path-
> 12.html#name-association-type
>
> You can find below the AD's approval.
>
> Thank you,
>
> Dhruv & Julien, PCE WG co-chairs
>
>
>  Forwarded Message 
> Date:   Mon, 13 Nov 2023 11:47:58 +
> From:   John Scudder 
>
>
>
> Approved.
>
> —John
>
> > On Nov 9, 2023, at 11:31 AM, julien.meu...@orange.com wrote:
> >
> > 
> > [External Email. Be cautious of content]
> >
> > Hi John,
> >
> > The authors of draft-ietf-pce-sr-bidir-path have requested for the
> > early allocation of the codepoint specified in:
> >
> > https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-
> > 12#name-iana-considerations
> >
> > We polled the WG and there were no objections. According to the
> > chairs’ review, the RFC 7120 criteria is met.
> > As per the process in the RFC, we now request your approval before
> > reaching out to the IANA for the early allocation.
> >
> > Thanks!
> >
> > Dhruv & Julien
> >
> >
> >  Forwarded Message 
> > Date: Thu, 9 Nov 2023 17:10:42 +0100
> > From: Julien Meuric 
> >
> >
> > Hi all,
> >
> > No concerns have been expressed about this early allocation. We'll
> > thus proceed to the next step.
> >
> > Thanks,
> >
> > Dhruv & Julien
> >
> >
> > On 28/07/2023 15:58, Julien Meuric wrote:
> >> Hi WG,
> >>
> >> We have received a request from the authors of
> >> draft-ietf-pce-sr-bidir-path for an early code point allocation on
> >> the association type referred to in
> >> https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path-
> >> 11#name-iana-considerations
> >>
> >> RFC 7120 requires to meet the following criteria to proceed:
> >>
> >> b. The format, semantics, processing, and other rules related to
> >> handling the protocol entities defined by the code points
> >> (henceforth called "specifications") must be adequately described
> >> in an Internet-Draft.
> >> c. The specifications of these code points must be stable; i.e., if
> >> there is a change, implementations based on the earlier and later
> >> specifications must be seamlessly interoperable.
> >>
> >> If anyone believes that the draft does not meet these criteria or
> >> believes that early allocation is not appropriate for any other
> >> reason, please send an email to the PCE mailing list explaining why.
> >> If the chairs hear no objections by Monday August 21st, we will kick
> >> off the early allocation request.
> >>
> >> 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] IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

[Dhruv Dhody]

Hi Authors,



In preparation for WG adoption on this draft, we'd like all authors 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,

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

[Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Dhruv Dhody]

Hi WG,

This email begins the WG adoption poll for
draft-sidor-pce-circuit-style-pcep-extensions-05.

https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/

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 Friday 15th Dec 2023.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] The PCE WG has placed draft-sidor-pce-circuit-style-pcep-extensions in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The PCE WG has placed draft-sidor-pce-circuit-style-pcep-extensions in state
Call For Adoption By WG Issued (entered by Dhruv Dhody)

The document is available at
https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/


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

Re: [Pce] In prep for adoption call for draft-sidor-pce-circuit-style-pcep-extensions

[Samuel Sidor (ssidor)]

Just to keep mail thread updated.

New version submitted (and thanks again for your comments Dhruv).

Regards,
Samuel

From: Samuel Sidor (ssidor) 
Sent: Monday, November 27, 2023 10:27 AM
To: Dhruv Dhody ; 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs ; pce@ietf.org
Subject: RE: In prep for adoption call for 
draft-sidor-pce-circuit-style-pcep-extensions

Hi Dhruv,

Please see inline .

Thanks a lot,
Samuel

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Saturday, November 25, 2023 6:23 AM
To: 
draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org
Subject: In prep for adoption call for 
draft-sidor-pce-circuit-style-pcep-extensions

Hi,

Can you please upload a new version of the I-D that tidies up the document in 
preparation for WG adoption call?

- Limit the number of authors to 5
 I’ll discuss with existing co-authors and I’ll move some of them to 
contributors.
- Add text to the security consideration section (add references to relevant 
rfcs if no new security threat is assumed)
 I’ll add pointers to security considerations from RFC5440, RFC8231, RFC8281 
and potential consideration for using best practices from RFC7525.
- Think about adding a mangebility consideration
 I’ll add it.
- Instead of saying that the applicability to RSVP-TE and SR-TE better yet say 
it is applicable to all path setup types!
 Makes sense, I’ll update it.
- I am confused by - "For example

   Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if
there is only one adjacency). the PCE MUST use Adjacency SIDs only."; are Adj 
SID "MAY" or "MUST"?? It should be MUST right?
 There was discussion between co-authors to allow adjacency SIDs, block 
prefix SIDs, but still maintain future compatibility for any other SID type if 
needed, so we wanted to avoid MUST statement. I’ll drop second statement.
- What is the way to indicate that a computed path no longer meets the original 
constraints when the recomputation is blocked? Isn't that something that is 
useful for operators to know?
 Operators are notified, but they are notified from PCE (northbound 
direction) – behavior also depends on flags set in that TLV:
- if P flag is cleared, PCE can still re-compute if constraints are not 
satisfied (I assume that you are not talking about this case)
- if P flag is set and F flag is cleared, then operators are notified on PCE 
and they may decide to trigger manual re-computation on PCE as described in CS 
SR policy 
draft
- if P flag is set and F flag is set, then there is no way to update LSP, so 
assumption is that operator does not want PCE to monitor validity of that path 
and it relies on liveness detection done by headend 
(reference),
 which is obviously not monitoring some set of constraints.
- When the P flag is cleared or the TLV is not present, we fall back to the 
existing scenario and in which one would assume PCE does the recomputation 
based on various triggers yet the draft uses "MAY recompute"... could this be a 
"SHOULD"?
 Even “SHOULD” is probably not ideal (but I agree that probably better than 
“MAY” in this case) – I’ll think about it a bit if I can re-phrase it.
- Add implementation Status if you have plans of implementations!
 Sure, I can add it.

Thanks!
Dhruv


--- Begin Message ---
A new version of Internet-Draft
draft-sidor-pce-circuit-style-pcep-extensions-05.txt has been successfully
submitted by Samuel Sidor and posted to the
IETF repository.

Name: draft-sidor-pce-circuit-style-pcep-extensions
Revision: 05
Title:PCEP extensions for Circuit Style Policies
Date: 2023-12-01
Group:Individual Submission
Pages:12
URL:  
https://www.ietf.org/archive/id/draft-sidor-pce-circuit-style-pcep-extensions-05.txt
Status:   
https://datatracker.ietf.org/doc/draft-sidor-pce-circuit-style-pcep-extensions/
HTML: 
https://www.ietf.org/archive/id/draft-sidor-pce-circuit-style-pcep-extensions-05.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-sidor-pce-circuit-style-pcep-extensions
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-sidor-pce-circuit-style-pcep-extensions-05

Abstract:

   This document proposes a set of extensions for Path Computation
   Element Communication Protocol (PCEP) for Circuit Style Policies -
   Segment-Routing Policy designed to satisfy requirements for
   connection-oriented transport services.  New TLV is introduced to
   control path recomputation and new flag to add ability to request
   path with strict hops only.



The IETF Secretariat


--- End Message ---
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/