Re: [Pce] Martin Duke's No Objection on charter-ietf-pce-07-03: (with COMMENT)

[Dhruv Dhody]

Hi Martin,

On Tue, Nov 28, 2023 at 12:25 AM Martin Duke via Datatracker <
nore...@ietf.org> wrote:

> Martin Duke has entered the following ballot position for
> charter-ietf-pce-07-03: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-pce/
>
>
>
> --
> COMMENT:
> --
>
> This group appears to have a fair amount of overlap with the soon-to-close
> ALTO, but that certainly does not prevent rechartering.


Dhruv: I would categorize that PCE and ALTO "complement" each other rather
than "overlap".



> Arguably, CATS is also
> related, but that's not my WG so I'm sure the relevant ADs will work that
> out.
>
>
Dhruv: There is a possibility in future for it but as of now there is no
work proposed nor it is listed in the CATS charter.



> Is TED synchronization in or out of scope?
>
>
>
Dhruv: Yes if PCEP is being used for such synchronization. One could say
its implicit in stateful PCE, but may be we can make it explicit -

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.


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

[Pce] Martin Duke's No Objection on charter-ietf-pce-07-03: (with COMMENT)

[Martin Duke via Datatracker]

Martin Duke has entered the following ballot position for
charter-ietf-pce-07-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-pce/



--
COMMENT:
--

This group appears to have a fair amount of overlap with the soon-to-close
ALTO, but that certainly does not prevent rechartering. Arguably, CATS is also
related, but that's not my WG so I'm sure the relevant ADs will work that out.

Is TED synchronization in or out of scope?



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

[Pce] Publication has been requested for draft-ietf-pce-pceps-tls13-02

[Julien Meuric via Datatracker]

Julien Meuric has requested publication of draft-ietf-pce-pceps-tls13-02 as 
Proposed Standard on behalf of the PCE working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/


___
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)]

Hi Dhruv,

Please see inline .

Thanks a lot,
Samuel

From: Dhruv Dhody 
Sent: Saturday, November 25, 2023 6:23 AM
To: draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org
Cc: pce-chairs ; 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


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