Hi Julien/All, Thanks for all the work put into this document by the authors and the WG. It is an important specification for SRv6 deployment.
I believe the document needs a little more work to discuss/fix some issues before it is ready for publication. Major: -------- 1) I have concerns with the inclusion of SRv6 MSD types in the PCEP SRv6 Capability even if MSD is there in the PCEP Capability for SR-MPLS. Firstly, the MSD info about the node is already made available to the PCE as part of the topology information via IGP/BGP-LS and having it also in PCEP is a duplication in information. In the case of SR-MPLS, the MSD specs developed in parallel in PCEP/IGP/BGP-LS and perhaps led to what we have there. Secondly, and more importantly, in SR-MPLS the MSD capabilities (BMI MSD type) of only the PCC/headend was important. When it comes to SRv6, the PCC/headend MSD alone does not suffice for path setup. The PCE needs to consider the capabilities of the Segment Endpoint nodes in the middle and also the ability of the tail end node to perform the necessary disposition. Possible Solution: Since it is too late to remove MSD info, we can make it optional and say that it SHOULD NOT be used/signaled via PCEP. We also need clear guidelines that the PCE needs to check the MSD capabilities of mid and tail end nodes as well before signaling the SRv6 path to the PCC. 2) The X bit in the SRv6 PCE Capability seems odd even if it was there in SR-MPLS. I don’t see how practically there can’t be any limits for SRv6. A PCC can simply advertise the value of 255 if it is capable instead of the X bit. Another alternative is for PCE implementations to provide a knob to overrule whatever MSD is signaled by the PCC (not sure if this is even a good idea). Do any of the current PCC implementations set this X flag and if so, why? 3) What happens when there is a mix of SRv6 and other ERO object types for a given path? I believe this should be flagged as an error by PCEP? 4) When the endpoint behavior is not known, the Opaque value 0xFFFF needs to be used in the SRv6 ERO to be consistent with other signaling protocols and RFC8986. The value of 0 is invalid per RFC8986 and should not be used. 5) The SRv6 ERO Endpoint behavior field says that “This information is optional and plays no role in the fields in SRH imposed on the packet.” I am not sure that statement is accurate since it rules out the behavior influencing how the segments are encoded into the SRH. This may not always be the case. In fact, the specification should recommend that the behavior be always signaled when possible. 6) The document talks about forming SRH and putting it on packet, etc. All of these are outside the scope of PCEP. These are covered by RFC9256 & RFC8986 and should not be included in this document. E.g., in Sec 5.2.2 we have “The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus a next hop. The PCC sends packets along the segment routed path by prepending the SRH onto the packets and sending the resulting, modified packet to the next hop.” There are other similar texts. Please consider removing all of them and it is better to just stick to purely PCEP protocol operations. Minor: --------- a) I was hoping that we could have flipped the semantics of the S and F flags for the SRv6 ERO ☹ … it is odd that a bit being set indicates absence of an optional encoding. Nits: ------ In the Abstract: s/The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used/Segment Routing (SR) can be used The following statement is incorrect as explained in the introduction section: It depends only on "segments" that are advertised by Link-State IGPs. In Section 1: The following statement is not very clear: Segments can be derived from different components: IGP, BGP, Services, Contexts, Locater, etc. In Section 3.1: The following statement is not really accurate: In SR networks, an ingress node of an SR path appends all outgoing packets with an SR header consisting of a list of SIDs (IPv6 Prefix in case of SRv6). I hope this helps improve the document to get it ready for publication. Thanks, Ketan On Mon, Feb 13, 2023 at 11:09 PM <julien.meu...@orange.com> wrote: > Dear PCE WG, > > This message starts a 2-week WG last call on > draft-ietf-pce-segment-routing-ipv6-15 [1]. Please, be express any > comments you have about this document using the PCE mailing list. > > This WGLC will end on Tuesday 28th February 2023. > > Thanks, > > Julien > > -- > [1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/ > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
