IETF 119 PCE WG Minutes
Tuesday, 19 March 2024, Session III, 15:30 - 17:00 GMT+10
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
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.