IETF 115 PCE WG Rough Minutes

Friday, 11 November 2022 12:00 - 13:30 UTC
Kensington 2

• Chairs: Dhruv Dhody, Julien Meuric
• Secretary: Hari (Hariharan Ananthakrishnan)
• Slides
• Video
• Chat-Stream
• Meetecho Recording

Introduction

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

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

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

• [John Scudder] draft-koldychev-pce-operational. We can do either
  way unified vs two draft. Often I would prefer one draft just to
  progress fewer document. But in this case, One standards document
  and one informational document that can provide as much color,
  commentary and detail would work well to make it easier to move
  through IESG. I would encourage WG to consider the two document
  option.

PCEPS

2.1 TLS1.3 for PCEP (Sean/Russ, 10 min) [40/90]

draft-dhody-pce-pceps-tls13-01

• [Julien] I believe this is a straightforward draft. Polling in
  progress. 100% support (raise of hand). We will send questions to
  mailing list about adoption of this document.

Segment Routing

3.1 Mirror Binding (Huaimo Chen, 10 min) [50/90]

draft-chen-pce-mbinding-00

• [Andrew Stone] This creates an assumption that the neighbor has
  sufficient capability to push the SID stack of the BSID. Imagine the
  BSID has X labels that need to be pushed by the neighbor and cannot
  do it. It also assumes the neighbor has visibility into the SID
  within the BSID
• [Huaimo Chen] We assume that IGP will distribute those kinds of
  adjacency information.
• [Andrew Stone] Should have PCE push the path to protect the BSID
  to the neighbor. It handles other situations like Multi-Domain,
  PCECC. It opens a lots of flexibility. I am worried that we might be
  repeating different descriptions in PCE and IDR WG. So I am
  wondering if the solution should be taken out into Routing working
  group or even SPRING and then worry about the encoding after the
  fact. In our discussions there are a few different ways to solve it
  and I think there needs to be some consistency on how we want to
  solve.
• [Huaimo Chen] We already have a protection draft in SPRING. In
  order to provide protection for node failure we need a PCE or IGP
  IDR extension, that's why we come here. We already have a draft of
  protecting binding SID in SPRING.
• [Andrew Stone] I might have missed that, I will take a look at it.
  Clarifying how we want to protect like multi-area etc, then work on
  encoding after that.
• [Huaimo Chen] For multi-domain case we need to have egress
  protection. The border node will have a backup border node and in
  that case, the backup bordernode will have the information about the
  other domain.
• [Andrew Stone] It is debatable if its considered an egress node,
  since the tunnel is end-to-end and the binding sid is still part of
  that end-to-end packet. There is no de-encapsulation at that point.
  When its leaving a domain, it is still part of the tunnel, its just
  egressing the domain. The egress protection is more applicable on
  the egressing of the tunnel than egressing of the domain.
• [Huaimo Chen] Yes, I agree. Since this is a border node.
• [Dhruv] As a contributer, I agree with lot of things that Andrew
  mentioned. We should take the core of things that is available in
  RTGWG/SPRING. Then extension of that will belong to the PCE WG.
  Let's postpone the encoding discussion and focus on, at a higher
  level, what all information that we need to pass to make this mirror
  binding work.
• [John Scudder] +1. Please do the work once in a group that has the
  core expertise to get the architecture right and then it will be
  really easy to do the rest of it here.

Stateful & PCECC

4.1 IFIT (Giuseppe Fioccola, 10 min) [60/90]

draft-ietf-pce-pcep-ifit-01

• No comments.

4.2 PCE Controlled Identifier Space (Hang Shi, 10 min) [70/90]

draft-li-pce-controlled-id-space-13

• [Dhruv] The document is already in WG adoption queue. Is there any
  concern from any one/any comments?
• [Cheng Li] Thank you for the presentation. The content is stable
  and asking for WG adoption.

4.3 PCE-initiated IP Tunnel (Hang Shi, 10 min) [80/90]

draft-chen-pce-pce-initiated-ip-tunnel-02

• [Andrew Stone] The root question I have is: "Why use PCEP for this
  if there is no path to compute?"
• [Hang Shi] You can think of the tunnel as some kind of path you
  traverse the WAN because there will be multiple choice.
• [Andrew] Can you use Netconf to provision the tunnel? I don't see
  the benefit of using PCE for this. You are not doing path
  calculuation. It just feels heavy to me.
• [Hang Shi] When you create a tunnel you can attach a TE metric to
  request a certain internal corresponding to this TE Metric.
• [Zhenbin Li] In fact this work has been proposed several years
  ago. We identified new use-cases like SDWAN. We want to use PCE for
  better performance and scalability.
• [Ketan Talaulikar] In the introduction section of the draft, it
  has been mentioned that this tunnel is used to address the label
  stack/MSD isssue. It is different from what was presented today. I
  would suggest you add more text to understand the use-cases.
• [Zhenbin Li] Thanks for the suggestion. We have another draft that
  talk about the application scenarios. We will send in the mailing
  list for reference.
• [Dhruv] Thanks for the comments. The motivation is needed in the
  draft itself. We need to clearly specify why we need this
  functionality. Why do we need PCEP in the context of IP tunnel? When
  it comes to encoding, do we need new set of messages or do we use
  the path setup type fields we already have? We allow path setup
  types to handle SRv6 which is a sort of IP tunnel in a way. We need
  consensus on whether we have enough motivation in this working group
  to do IP tunnel via PCEP.

[Julien] Thank you for attending. Hopefully see you in Yokohama.