# IETF 115 PCE WG Rough Minutes   {#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][1]
*   [Video][2]
*   [Chat-Stream][3]
*   [Meetecho Recording][4]

### Introduction   {#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   {#pceps}

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

[draft-dhody-pce-pceps-tls13-01][5]

*   \[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   {#segment-routing}

3\.1 Mirror Binding (Huaimo Chen, 10 min) \[50/90\]

[draft-chen-pce-mbinding-00][6]

*   \[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   {#stateful--pcecc}

4\.1 IFIT (Giuseppe Fioccola, 10 min) \[60/90\]

[draft-ietf-pce-pcep-ifit-01][7]

*   No comments.

4\.2 PCE Controlled Identifier Space (Hang Shi, 10 min) \[70/90\]

[draft-li-pce-controlled-id-space-13][8]

*   \[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][9]

*   \[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.



[1]: https://datatracker.ietf.org/meeting/115/session/pce
[2]: https://www.youtube.com/watch?v=HmfAsbGxd5w
[3]: https://zulip.ietf.org/#narrow/stream/pce
[4]: https://play.conf.meetecho.com/Playout/?session=IETF115-PCE-20221111-1200
[5]: https://www.ietf.org/id/draft-dhody-pce-pceps-tls13-01.html
[6]: https://www.ietf.org/archive/id/draft-chen-pce-mbinding-00.html
[7]: https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-ifit-01
[8]: https://www.ietf.org/archive/id/draft-li-pce-controlled-id-space-13.html
[9]: https://www.ietf.org/archive/id/draft-chen-pce-pce-initiated-ip-tunnel-02.html