[Pce] A review of draft-ietf-pce-state-sync-07

[Adrian Farrel]

Hi,

As this document approaches being ready for working group last call, I
thought it might be helpful if I did a review.

Cheers,
Adrian

===

The document title could do with some clean-up.
- Remove the full stop
- Perhaps make it more straight-forward. For example,  Procedures for
Communication between Stateful Path Computation Elements

---

Abstract para 2

s/an LSP/LSP/

---

Abstract para 3

s/a stateful/stateful/

---

1. para 2

s/paths,/paths)/

---

1. para 4

s/an LSP state/LSP state/
s/of a LSP/of an LSP/
s/to only a single PCE/to a single PCE/

---

1.

s/to allow a stateful/to allow stateful/

---

1.

OLD
   Further, the examples in this section are for illustrative purpose to
   showcase the need for inter-PCE stateful PCEP sessions.
NEW
   This section contains illustrative examples to showcase the need for
   inter-PCE stateful PCEP sessions.
END


However, I find the examples running through sections 1.2, 1.3, and 1.4 to
be quite unnecessary. There is a feeling of "trying too hard" to prove that
there are uses for the protocol extensions described in the body of the
document. I would have been very happy with just one paragraph listing out a
few of the possible use cases.

Further, section 4 (which seems to rework the examples in sections 1.2, 1.3,
and 1.4) is not really an explanation of how the protocol extension works,
but more of a set of use cases. Again, this feels like it is trying to prove
the value of the extension. Do we really need it? It is such a simple
protocol extension.

---

1.2 para 1

s/an LSP state/LSP state/
s/grants the control/grants control/

---

1.2 para 2

This is really to read.

   In a multi PCE deployment (redundancy, loadbalancing...), with the
   current specification defined in [RFC8231], when a PCE makes an
   update, it is the PCC that is in charge of reporting the LSP status
   to all PCEs with LSP parameter change which brings additional hops
   and delays in notifying the overall network of the LSP parameter
   change.

a) s/current specification/specification/

b) s/with LSP parameter change/with any LSP parameter changes/

c) I can't tell what the final part of the paragraph means. Is it the
   reporting that brings additional hops and delays? How does the
   reporting cause this?

---

1.2 para 4

s/As stateful PCE make/As a stateful PCE makes/

s/immediately to/to/

---

All the figures in the document need numbers and titles. The text should
refer to them using  rather than "the figure above" etc.

---

1.2

OLD
   PCE1 is responsible to compute paths for PCC1 and PCE2 is responsible
   to compute paths for PCC2.
NEW
   PCE1 is responsible for computing paths for PCC1, and PCE2 is
   responsible for computing paths for PCC2.
END

OLD
   PCE2 will so
   be notified of the change only after receiving the PCRpt message from
   PCC1.
NEW
   So PCE2 will
   be notified of the change only after receiving the PCRpt message from
   PCC1.
END

---

I'm confused by the example given in 1.2. LSP1 is under the control of PCE1,
so any changes that are made are made with the direct instruction from PCE1.
Therefore, it is not necessary to wait for the change to be reported by PCC1
- PCE2 can be notified of the intended change. Surely that would be more
efficient. (Yes, that would only be possible if there is a session between
the PCEs.)

Additionally, when the change is made in the network, it seems unlikely to
me that PCC1 would be aware that it is LSP2 that has had its resources
reduced because PCC1 does not know about the existence of LSP2. However, the
network nodes servicing LSP2 would know about this and so it would be
reported to PCC2 which can report it direct to PCE2.

(Note that this does not take anything away from the proposed protocol
extension. It is just a confusing example.)

---

1.3

s/failure, PCC/failure, the PCC/
s/sending new/sending a new/
Expand 'ERO' on first use.

---

1.3

   When the failed PCE or PCEP session comes back online, it will
   be up to the implementation to do preemption.  Doing preemption may
   lead to some disruption on the existing path if path results from
   both PCEs are not exactly the same.

The term 'preemption' may cause some confusion. I don't think you are
referring to the type of preemption of resources mentioned in the example in
the previous section. Perhaps...

   When the failed PCE or PCEP session comes back online, it will
   be up to the implementation whether to revert back to the original 
   primary PCE.  Reverting may lead to some disruption on the existing
   path if computation results from both PCEs are not exactly the same.

---

1.3

   By considering a network with
   multiple PCCs and implementing multiple stateful PCEs for redundancy
   purpose, there is no guarantee that at any time all the PCCs delegate
   their LSPs to the same PCE.

There is something not quite right about this sentence. Is there a 'not'
missing, such as...

   By considering a network with
   multiple PCCs and im

[Pce] pce - Requested session has been scheduled for IETF 120

["IETF Secretariat"]

Dear Dhruv Dhody,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


pce Session 1 (1:30 requested)
Thursday, 25 July 2024, Session III 1500-1630 America/Vancouver
Room Name: Regency A/B [Breakout 6] (size: 300)
-


iCalendar: https://datatracker.ietf.org/meeting/120/sessions/pce.ics

Request Information:


-
Working Group Name: Path Computation Element
Area Name: Routing Area
Session Requester: Dhruv Dhody


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 75
Conflicts to Avoid: 

   


Participants who must be present:
  Andrew Stone

Resources Requested:

Special Requests:
  Do not schedule against BOFs if possible.
-


___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[Samuel Sidor (ssidor)]

Hi Cheng,

Sorry for delayed response.


  1.  PCOpen
I would personally prefer to decouple PCEP session from ID space advertisement 
as there is no logical connection between them, so to me this option seems to 
be least preferred one.

  1.  Use PCEP-LS encoding and make this a node attribute
I’m fine with using PCEP-LS encoding, but ideally without requiring full 
support of PCEP-LS draft as that dependency may be too big for vendors, which 
does not need to support it, but still want to exchange some specific ID space

  1.  New type of notification
  2.  New message/object
I’m fine with both options above, but completely new message type may be 
cleaner approach, ideally with some message type, which can be re-used in the 
future (not too specific for this usecase).

Thanks a lot,
Samuel

From: Cheng Li 
Sent: Thursday, June 27, 2024 5:09 PM
To: Cheng Li ; pce@ietf.org
Subject: [Pce] Re: Where the Controlled ID info shuold be carried/encoded?

Echo request 😊

Hope to have your valuable suggestions!

Thanks,
Cheng


From: Cheng Li 
mailto:c.l=40huawei@dmarc.ietf.org>>
Sent: Thursday, June 20, 2024 11:46 AM
To: pce@ietf.org
Subject: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

l  Open message

l  Use PCEP-LS encoding and make this a node attribute

l  New type of notification

l  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org