IETF 115 PCE WG Rough Minutes
Friday, 11 November 2022 12:00 - 13:30 UTC
Kensington 2
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
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.