IETF 119 PCE WG Minutes

Tuesday, 19 March 2024, Session III, 15:30 - 17:00 GMT+10

• Chairs: Dhruv Dhody, Julien Meuric
• Secretary: Andrew Stone
• Note Taker: Andrew Stone
• Slides
• Video
• Chat-log
• Meetecho Recording

IETF 119 PCE WG Agenda

Introduction

1.1. Administrivia, Agenda Bashing (Chairs, 5 min) [5/90]

1.2. WG Status (Chairs, 10 min) [15/90]

• [Julien] Early IANA allocation for Multipath I-D is expiring in
  May, should be good to update in the near future.

1.3. State of WG I-Ds, open issues and next steps (Chairs, 15 min)
[30/90]

• [Dhruv] For early allocation of code points please pay attention
  to the timing. We get the allocation for 1 year, followed by 1 year
  renewal. Ideally, allocation should happen considering that
  timeframe rather than much earlier.

Stateful PCE

2.1 Optional Processing of Objects (Cheng Li, 10mins) [40/90]
draft-ietf-pce-stateful-pce-optional

• [Dhruv] For text the authors did not accept, please can you make
  your point across. Samuel mentioned the backward compatibility
  section, but I think this text was sufficient. RFC 5440 said you
  have P and I flags and RFC 8231 says flags for new objects are
  ignored but did not comment on existing objects. We have some
  undefined behaviour with existing objects in stateful messages. Most
  implementations seem to always ignore them so we may not have any
  dire effect, but what is the correct thing to do in the document?
• [Samuel] Confirming that I'm fine with the change that was
  proposed. Most implementations ignore them, so better to be safe
  with the text as is.

2.2 State Synchronization (Cheng Li, 10mins) [50/90]
draft-ietf-pce-state-sync

• [Dhruv] This is the open issue we should resolve (open message).
  To summarize. Open has a lot of information such as capability and
  other things like MSD sent during the initial open message exchange.
  Now when a PCE makes a session to another PCE, and delegates LSP to
  it, that information we don't carry to other PCEs. This loss of
  information could make different sets of information in the PCEs and
  could have a computational impact. This is a good point that Andrew
  highlighted, which was missed. The authors claim that can keep it
  open for now, and acknowledge it's missing, but this doc doesn't
  specify. The first question for WG - is this okay? can we leave it
  open? or should not leave it open? Was talking to the authors, few
  ideas on how to solve it. One suggestion might be to carry the open
  message information as part of a delegation of the LSP but seems
  hacky. Another option is one notification, various ideas but not
  straightforward. Authors say most of their issues are solved like
  split brain, computation loop etc. If WG disagrees then we can
  direct authors to handle this as well.
• [Andrew] Thanks for taking the suggestions on the edits to the
  document. To do state sync fully with sufficient information you
  need that open message. This goes 95% of the way, 5% overlooked. How
  to do the 5% is open to me, carrying the open message as part of the
  delegation feels hacky. Whether it has to be in this document, as WG
  we need to decide. The concern is if we don't put it here, what
  other gaps are we going to miss between PCE exchange and other use
  cases that pop up later with this? Maybe we define a new object, not
  a new message. No concrete answer yet.
• [John] My assumption is this is a pathology you're describing and
  not expected behaviour, and it would happen maybe if configuration
  changed or something on PCE, after the establishment of the first or
  second session - is this generally correct?
• [Dhruv] Even in normal operation with sub-delegation that scenario
  happens where there's information missing on PCE that it normally
  could have had, for example, sub-delegation primary and secondary.
  You might not have a session to the secondary so sub delegation
  missing what it would have if it had a direct session. Not a
  scenario that might happen, but missing.
• [John] Ok not a might but a will. No special weight (to feedback
  as AD), but tend to agree that we should try to make it a finished
  spec rather than 95%
• [Pavan in chat] +1 to what Andrew said
• [Dhruv] If anyone wants to disagree and push the document out
  right away, please say something. Otherwise, most likely direction
  to authors to come up with a proposal. Andrew if you have thoughts
  on the best way to do it, please continue that discussion on the
  mailing list.
• [Andrew] Yeah will come up with text or ideas. I mentioned 95%
  because it does cover the use cases described in the document and
  can be accomplished but depending on other use cases the lack of
  open message info can affect things. Will follow up and work on
  figuring it out.

Segment Routing

3.1 SR P2MP Policy (Hooman Bidgoli, 10mins) [60/90]
draft-ietf-pce-sr-p2mp-policy

• [Dhruv] For the TLVs - was just checking, are we saying that the
  format of the TLVs has to change? or the format is the same?
• [Hooman] All the same TLVs including the format of the TLVs(as
  unicast), except maybe CPATH-ID TLV since that needs to carry root
  ID. May need to double-check
• [Dhruv] Suggest if the format is different then should be a
  different TLV codepoint
• [Dhruv] If PCE is setting LSPID, does it affect stateless? would
  it make sense to have a stateless request?
• [Hooman] The solution supports and makes sure to handle
  PCC-initiated
• [Andrew] It is stateful implicitly because the transit replication
  segments need to be pushed, so no use case for stateless on the
  headend
• [Dhruv] Also many authors, should be within 5
• [Hooman] Yes, many people helping out so will tune

3.2 Circuit Style Policy (Samuel Sidor, 10mins) [70/90]
draft-ietf-pce-circuit-style-pcep-extensions

• no comments/discussion

Others

4.1 Bounded Latency (Quan Xiong, 10 mins) [80/90]
draft-xiong-pce-detnet-bounded-latency

• [Dhruv] The document referenced in detnet is already adopted?
• [Quan] Yes the requirements document is already adopted in detnet
• [Dhruv] Since it is adopted, will chat with Julien and we can add
  it to our queue
• [Dhruv] We already have latency and jitter metrics, how do they
  interact? or can they be included?
• [Quan] The existing specifications define the path computation,
  and it defines basic computation over the sum but detnet has a
  difference
• [Dhruv] Yes, they are both different but what if they both
  carried? Do we need text to say one wins?
• [Quan] Yes, some text on how to compute is in the document
• [Dhruv] Regarding ERO - you have 3 types, are they used together
  or only one used at a time? What's the usual way it's used?
• [Quan] Only one at a time. Similar to NAI as SR ERO.
• [Dhruv] Okay makes sense. If you can add that description a little
  bit better would be good for the reader. Action items for us on the
  chairs to reach out to the detnet chairs to figure out the next
  step.

4.2 Precision Availability Metrics (Luis, 10 mins) [90/90]
draft-contreras-pce-pam

• [Quan] Two concerns. First is proposed the time unit - rfc8233
  metric used microseconds, coded with 32 bits, so this is the minimum
  units of time. If it's required to describe other periods like day,
  year, etc. then needs to change. The second concern is how to use
  this metric together with existing metrics like path delay and
  bounded latency
• [Luis] Granularity, in the draft we are proposing several degrees
  of it. I think we cover that front but need to check. In parallel
  with other metrics, not all can be via precision. Will depend on the
  nature of the service and the SLAs. Some can use precision, and some
  not. This could apply to your proposal(bounded latency) but will
  need to recheck it. Depending on metric they may coexist.
• [Quan] Maybe can discuss it on the mailing list.
• [Dhruv] General comment I made earlier. When metric type is
  introduced in detnet or this, if we try to keep it in the same
  format it's good for the protocol extensions. If we come up with new
  ones, we should not have new ones for different metric types. If a
  new object is needed might need alignment.
• [Dhruv] What is the applicability for PCEP? delegated lsps and
  monitor over time? Need applicability and error cases and don't use
  it in these other scenarios. This can be useful to add.
• [Luis] Got it, will work on that.