Chairs:
Bruno Decraene
James Guichard
Joel Halpern
Secretary:
Shuping Peng
===============================================================================
March 25, 2022
12:30-14:30 Friday Afternoon session I (UTC+1)
Bruno introduced the progress of this WG.
The WG has produced a lot of good work. It would be good if we continue to focusing on the technical work. Happy to be contacted and discuss on technical work together.
Ketan Talaulikar: It is good to also consider SR-MPLS. Regarding slide 7, I agree that it is better not to decompose the C-SID container, and it will not bring any added value.
Andrew Alston: To C-SID, do you also refer to G-SID? Are they the same, or there is any difference?
Thomas Graf: I am not aware of G-SID. I will double check and then will let you know.
Darren Dukes: Regarding the decomposition, it is better not to decompose.
Thomas: ok.
Looking for WG adoption.
Salih: End.DPM, we have similar behavior defined in another draft which will also be presented in this WG.
Swadesh Agrawal: This function has been defined very early. We can discuss more.
Dhruv Dhody: With the PCE Chair hat on, is there any gaps for PCEP?
Swadesh Agrawal: I don't see any gap. But I can work with you.
Dhruv Dhody: The single PCE is clear. But for the multiple PCE, it may be tricky. There is a WG draft talking about the inter-domain stateful PCE. We should talk about it further.
Swadesh Agrawal: Sure, we will talk.
Zhenbin Li: The data plane for interworking is complex. I would like to encourage the operators to think about the requirements for the interworking scenario. More feedback would be good.
This draft has been presented in the PALS/MPLS/DetNet/SPRING Joint Meeting on Thursday.
Requesting MPLS WG adoption.
Jim Guichard: Has been discussed in MPLS DT?
Jaganbabu Rajamanickam: Yes
Jim Guichard: I also sent email to the authors but got no response. There are several drafts cover these formats. Please don't create duplicated work.
Jaganbabu Rajamanickam: Yes, we know about this. We have given the difference. No time to discuss in this meeting.
Jim Guichard: Ok
Cheng Li: Where is this movitation? We are inventing something like IPv6. We are just making MPLS very comlicated.
Jaganbabu Rajamanickam: The work is coming from different requirements. That is why the DT has been working.
Cheng Li: I get it. We have some issues in MPLS. But where is the value? Why not just directly go for IPv6?
Rakesh Gandhi: I hope SRv6 to be deployed everywhere. But in the meantime, there is still MPLS usage scenarios, e.g. OAM.
Greg Mirsky: Use cases have been documented as well as motivation and requirements. There should be more work before WG adoption.
Jeff Tantsura: IPv6 over MPLS is deployed and it is running now.
No comments.
Looking for feedback and comments
Linda Dunbar: For 5G, we need different paths from the source. Any draft describes it?
Robin Li: It is not for 5G end-to-end, It is for transport.
Linda Dunbar: In CAN, UE may use different slices. The source address may be used. Any draft decribes it?
Robin Li: This draft is not for this purpose. The traffic from UPF will first interwork with VPN and then go on mapping into the transport underlay. With one draft in the teas WG (draft-geng-teas-network-slice-mapping), we can directly map into the IETF slice. But it is still in the early stage.
Reza Rokui: To answer Linda's question, the creation of the IETF slices is different from the 5G UE using signaling to select the slices. The two work are orthogonal. I will send you the drafts if you like.
Please review and provide feedback
Greg Mirsky: Everything presented here can be achieved by iOAM and even more. iOAM will not impact the data flow. Happy to discuss on the mailing list more. This proposal is redundant.
Ahmed Adbelsalam: We aim from different angels. But happy to discuss in the mailing list.
Cheng Li: Same comments on the redundancy. This proposal may not be very accurate. Two years ago we had similar solution called light IOAM. I will send more information.
Ahmed Adbelsalam: We solve different problems. Path tracing can be used on different platforms.
Haoyu Song: Same opinion as Greg. iOAM can achieve the same goal. No need to have redundant solutions.
Pablo Camarillo: For the comparison with IOAM, it is very complex to support data export in the hardware. There is no way to solve it with iOAM. We are happy to discuss in the mailing list.
Requesting WG for adoption
Ken Talaulikar: Slide 6, Option C Interworking Example. Why do we need replace in this scenario? It is option C, why (node) 1 cannot directly reach (node) 16?
Salih: Why do we need two different replace behaviors (REPLACEB6 and REPLACE), right? If the ASes are only best effort or FlexAlgo that optimization can we do and we don't need additional encap. But if it has SRTE policy then we need. Because we need to first reach from one border to the other board so we need to replace first so the other board understand what to be processed next so the first change in destination we have to do. Then there is additional encap required for the upcoming domain. The SRTE path needs a new encap.
Ketan: There is a underlay BGP, which Replace needs to use. In the CAR or CT?
Salih: Yes.
Request for WG adoption and consider to include more use cases
Greg Mirsky: What is the relationshp between this draft and the ioam encapsulation in IPv6 in ippm wg?
Haoyu Song: This proposal is dedicated for the active ioam.
Greg Mirsky: ioam can also achieve everything you propose here, why to emphasize active ioam?
Haoyu Song: ioam can collect the data along the path. Other methods can only do the end-to-end.
Greg Mirsky: You are proposing a solution that has been solved.
Haoyu Song: Here we avoid all the issues. it could be deployed quickly.
Greg Mirsky: If you are not happy with the ippm draft why not raise it in ippm? Why drive two possible ways? It is not a good approach.
Haoyu Song: We already have stamp adopted here in SPRING. It is an easy way to go.
Greg Mirsky: The draft in SPRING WG (draft-ietf-spring-stamp-srpm?) is informational. Let's take it to the mailing list.
Dhruv dhody: SR policy have already defined composition policy? What is the difference?
Weiqiang Cheng: Slide 2, SR policy group is the same concept as the SR policy draft. In the SR policy draft, it did not give any usecase and how we can use it. Hope other operators can use our draft as a best practice.
Dhruv: But still it has been defined as composition policy. You should not deviate from the specification. I will take to the mailing list.
Mike Koldychev: When you say a special SR policy, it actually is a composition candidate path. Should keep using the same term in the SR policy draft.
Weiqiang: Understood. SR policy group is a hierachical concept. We may need to define more things.
Mike: Don't think so. You may say that policy for one candidate path that is composite.
Gyan: Could this work be combined with the SR policy draft?
Jim: That has been in the RFC queue?
Boris Khasanov: Please update this draft with implemenation status.
Jim and Joel: Sorry to the next draft, we dont have enough time.
No time to present.
Speaker Shuffling Time/Buffer: 5 minutes
Total Presentation Time: 115 minutes