Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

[Ketan Talaulikar <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>