IETF 121 PCE WG Minutes

Wednesday, 6th November 2024, Session III
15:00 - 16:30 (Dublin, Liffey A)
15:00 - 16:30 (UTC)

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

Introduction

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

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

• [Yi lin] - Regarding etsi liason - the liason more about asking
  for the protocols asking for control of the fgn. Currently in CCAMP
  and PCE we already have some draft which analyze using GMPLS and
  PCEP for control of the fgn, this contribution could be one of the
  response to the liason
• [Dhruv Dhody] - Thanks would be good to have a response on the
  mailing list to include your thoughts

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

• [Cheng Li via chat regarding state-sync status-update slide
  comment] - Update coming after the meeting

• [Quan Xiong via chat regarding draft-ietf-pce-entropy] - Thanks,
  will add implementation section in draft

• [Andrew Stone via mic regarding operational draft] - Yes lots of
  good content in there, will reach out the authors to see next steps
  about splitting that up

Segment Routing

2.1 PCEP extensions for Circuit Style Policies (Samuel Sidor, 10 mins)
[35/90]
draft-ietf-pce-circuit-style-pcep-extensions

• [Dhruv] - With respect to WGLC, whats the status in SPRING as of
  now? Was presented today during session?
• [Ketan Talaulikar] - Not an author but authors have asked for
  WGLC. There's some minor comments to be addressed, should come soon
• [Dhruv] - Let's time it appropriately, let SPRING past first
• [Samuel Sidor] - On mailing list discussing a corner case, more in
  opposite case, SPRING kind of has dependency on this since SPRING
  depends on extensions in - PCEP. (post-edited via recording)
• [Dhruv] - Audio was a bit unclear in room, helpful to write it
  down
• [Samuel via chat copy paste since audio speaker in room unclear] -
  I was just describing that it is more about SPRING CS draft
  depending on extensions PCEP CS draft (even if that is also not
  strong dependency)) rather than PCEP draft depending on SPRING
  draft.
• [Dhruv] - SPRING doc references a bunch, might need to become to
  be a cluster of all 3 docs going LC around same time
• [Zafar Ali] - Yes, authors have asked for last call, but not
  totally related and don't need the sequence

2.2 PCEP extensions for SRv6 Policy SID List Optimization (Zafar Ali, 10
mins) [45/90]
draft-ali-pce-srv6-policy-sid-list-optimization

• [Andrew] - Already talked before, and mentioned it in BGP but
  mentioning here for PCEP, would be good to have a section about MSD
  for validations since impact on ERO. Extra SID and maybe in some
  cases you don't pop it off it might overflow
• [Zafar] - Thanks, will add appropriate text
• [Dhruv] - Not sure, from an encoding pov what's the benefit of
  putting in lsp extended flag
• [Zafar] - To make sure it's per LSP, since unit of signalling is
  LSP for msging
• [Dhruv] - You mentioned needs to be same for all anyways, so small
  thing, we can discuss where to put this my feeling is look at
  everything, it feels like a property of SR-TE policy itself. From
  other side is it generic enough to put in LSP? Since it's limited to
  path setup SRv6. Gut feeling is inside SR policy container might
  have worked out better
• [Zafar] - Yeah from that pov, this is srv6 specific, that's why we
  put capability in srv6
• [Dhruv] - Also think about whehter capability needed or not. If
  flag is set or not or ignored, do we really need the flag. Let's
  talk through it just came to my mind
• [Zafar] - Capability was added for backward compat. reason but
  need depends on the traffic steering you need the indicator.
• [Dhruv] - Feels weird to set a flag to say i have a flag
• [Cheng] - Do agree we need flag in SR. Pol level and CP level but
  do think we need a flag for SID list. We can't assume that all SID
  list have it to reach endpoint, still discussion offline. Can bring
  up to mailing list can discuss there
• [Zaraf] - Sounds good. For the record since mentioned earlier
  dependiung on type of traffic steered all the SL needs to get the
  same treatment. With that in mind lets discuss if there's ever a
  case where we have to do per SL
• [Samuel] - Comment about sr policy or not, even now we do
  something like policy name is signalled for a CP. Either should be
  signalled once for complete policy but we kind of signal with the
  CP. We do need to duplicate the policy object anyways
• [Zafar] - Agree the unit of signalling for CP is LSP but happy to
  have that conversation

Stateful PCE

3.1 PCEP Extensions for updating Open Message content (Andrew Stone, 10
mins) [65/90]
draft-stone-pce-update-open

• [Ketan] - I think perhaps can learn and borrow from BGP, dynamic
  capability, a new message perhaps, all the objects can be encoded
  there with a marking that XYZ message capabilities cannot be
  modified or cannot be included in open refresh. List which
  capabilities could be included in both open and open refresh
• [Andrew] - Yes, perhaps in seperate message. Whether or not can be
  sent is in the initial open capability itself
• [Andrew] - yes for gotcha, and if reference already there from bgp
  lets borrow
• [Adrian] - I understand what you want to do and why, and sort of
  half support doing it, but then things get messy. In particular the
  how to handle state change not specified, obviously you don't want
  to but it opens up a mechanism that then needs to be backfilled for
  everything out there. If you don't, then who.
• [Andrew] - Good question, perhaps another is should we? or evolve
  over time
• [Adrian] - If evolve over time it could be splat in field
• [Andrew] - Should we examine all existing?
• [Adrian] - That worries me, both sides need to agree. It's
  unfortunate there's so much stuff out there. I support the idea if
  we add a flag in the open and we say I can tolerate these messages
  changing, maybe an open refresh TLV, like a bitmap of all the things
  I suppose open refresh on
• [Andrew] - Right, don't even send me if I don't support and flap
• [Adrian Farrel] - Right, and that might cover a lot, like, if
  there's a queue of requests because you support function, but now
  you withdraw that function, what do you do with that queue
• [Andrew] - Yes, seems similar with Ketan. Describe I can and
  cannot support modifying this open
• [John Scudder] - Following up to both of previous comments.
  Regarding Ketan, not aware of anyone implemented dynamic capability
  or not much traction. My impression is like what Adrian mentioned,
  has pointy bits. Doesn't mean not to do it, but tread carefully.
  Second part, points to another approach on BGP side - which also not
  as successful as one hopes, if changing bits in flight is too
  painful you could look at making resetting a session less painful.
  Make it low cost event, but don't have a solution
• [Andrew] - Regarding first, do you think it's because too broad
  and open? Wondering if what i'm hearing from group is maybe we
  should open how to do capability but don't backfill, only new stuff
• [John] - Think it's two, one is what you said, going back is
  really painful. Second part, think there's potentially a good way
  forward if just do this on a going forward basis
• [Stephane Litkowski] - Isn't this something we can handle like GR
  approach, flap the session, and keep the state, and do mark and
  sweep
• [Andrew] - Yes, a lot of implementation keep the state but you
  still need to do that sync.
• [Stephane] - Yes, mark and sweep it might be cleaner. Is flapping
  session really hurting? time you spend sending over the wire
• [Andrew] - There could be things ongoing, like delegation middle
  of computing for and alarms going off etc. But like you and Adrian
  mentioned, maybe a soft reset kind of thing
• [Andrew] - There could be things ongoing, like delegation middle
  of computing for and alarms going off etc. But like you and Adrian
  mentioned, maybe a soft reset kind of thing
• [Dhruv] - Think it's worth exploring what Stephane mentioned, we
  also have worked on state sync optimization draft, something we can
  build on in those approaches. Thanks for all the input

3.2 LSP State Reporting Extensions in PCEP (Samuel Sidor, 10 mins)
[55/90]
draft-sidor-pce-lsp-state-reporting-extensions

• [Andrew] - The BSID fallback, administratively, is that an update
  to existing or stand on its own? extract the BSID fallback on it's
  own document?
• [Dhruv] - Is something in RFC that needs to be updated? or more of
  an extension?
• [Andrew] - Don't know, existing says send send nothing, or send
  send, this basically now says send something but you might get back
  something different
• [Dhruv] - If there's some text now deviating from existing then
  it's an update
• [Samuel] - Is that an update even if there's new capability, not
  applicable to all PCCs.
• [Andrew] - Yeah, true fair enough. Only other comment is the two
  flags - quite like it. thanks.
• [Quan] - Remind, the E flag in lsp extended flag has been used in
  entropy label, so better to choose another letter or another flag
• [Samuel] - We can definitely do that thanks for bringing up
• [Dhruv] - Regarding transit eligible, if binding label is assigned
  then you are transit eligible. need to explicit signal.
• [Samuel] - Depends, bsid can be used for other purposes and want
  to explicitly specify. Still want BSID but not for path computation
  in pce. Just the existance of the bsid not sufficient
• [Ketan] - RFC9256 does have talk about bsid in general, and it's
  one of the way of steering is based on the BSID, and bsid can be
  assigned regardless of SR Policy. Some implemntation do that all the
  time. Seperate indication would be good
• [Dhruv] - Agreed, just want in document as well. Regarding
  explicit, is it always strict or can you have loose explicitly
  configured.
• [Samuel] - When loose it can be iro encoded as ero.
• [Dhruv] - It make sense to say that it is about strict explicit
  path
• [Samuel] - Yeah we can update to clarify with the IRO
• [Ketan] - RFC9256 could be loose explicit

Others

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

• [Janos Farkas] - Status update on detnet, recently adopted draft
  which will help with solutions. We still have not made any selection
  yet, discussing it tomorrow - the next step for selection. Many of
  the extension proposals have been regarding certain queueing
  proposals. Still not sure what is to be added to PCEP from a detnet
  WG perspective
• [Dhruv] - Thanks we can still talk about how fields are encoded
  while detnet is figuring other things out. My comment mainly thanks
  for adding sub object, the document says ERO is only made of the new
  detnet sub objects - but don't you need the path info as well?
  Clarity currently missing how does this interact with existing EROs
• [Janos] - One more note, not sure if this aligned to the detnet
  RFC information model. The trigger was the term jitter, my
  recollection is we use packet-delay-variation which is more specific
• [Dhruv] - Even in PCEP we use delay variation. since you define
  ERO, you need RRO as well. For DLL type, okay to do in this,m but
  last time we did something like this we had a bit of questions about
  NAI encoding choice, due to flag fields use for what fields to
  include. It's not that but each DLI type has it's own type and
  cleaner

4.2 Using PCEP over QUIC connection (Tingting Han, 10 mins) [85/90]
draft-yang-pce-pcep-over-quic

• [Andrew] - The slide mentions PCEP control channel and address
  families (AF), probably it is copy-paste from BGP over QUICK because
  PCEP does not have AF?
• [Tingting] - Yes, we borrowed from BGP
• [Andrew] - I don't see much benefits from QUIC for PCEP. The
  session are long live connections so not much benefit from the
  initial handshake and not multi channel benefits such as address
  families in BGP
• [Adrian] - I agree with Andrew' statement but we not say that some
  day QUIC will take ovet TCP so we need to run PCEP over Quic. Please
  have a look at Netconf over QUIC document to make some comparison
  and apply it.
• [Dhruv] - Should have a mechanism why this is needed. In
  discussions with authors it was mentioned there were some tests runs
  for when router and controllers fast away, would be good to get
  those numbers out to discuss them openly to see if there's a need
• [Tingting] - Thank you