Hi Zafar & authors
I reviewed the draft and have a few comments.
The draft is a sid list optimization providing an exclusion of the node
sid PCEP extension using a capability flag to signal to include or exclude
based on the use case scenario.
This idea seems very similar in context to RFC 8986 SRv6 PGM H.Encap.Red
head end behavior reduces the size of the SRH by one SID by excluding the
first SID in the SRH of the new IPv6 header, but now applying to the last
SID SR Policy endpoint.
So applying a similar optimization on the SR policy endpoint for static or
dynamic ODN or automatic steering where the endpoint node SID is defined in
the SID list and signaling in PCEP a flag for exclusion in cases where the
egress SID is not necessary.
I think it maybe good to run this draft by Spring WG on their thoughts on
the use case since it’s an SR architecture change to not include the
endpoint SID as I have noticed it is required for Linux kernel and FD.IO VPP
(Vector Packet Processing) but not for routers for static SID lists. I am
guessing PCE dynamic SID list may have the same requirement but should be
researched why so this can be changed as proposed in the draft.
Also this could be applicable to SRv6 Compression C-SID both next and
replace sid as well maybe SR-MPLS. We should mention in the draft.
In the draft it mentions the endpoint SID locator on the egress PE being
redundant if you have a service SID. I agree if the PCE adds the endpoint
SID and overlay service SID that is definitely redundant.
So the SR policy endpoint is a 2 tuple {color, endpoint}. The SR policy
endpoint should not be confused with the last SID in the SID list egress PE
Endpoint Node SID. When egress PE signaling RFC 9012 color extended
community color matches the SR head node SR policy color the BSID is
locally auto generated and binds the candidate path dynamic or static SID
list onto the SRv6 forwarding plane to the SR policy endpoint. In order
for the candidate path to be bound to the forwarding plane a key ingredient
is the SR Policy 2 tuple 2nd argument the endpoint must be routing
reachable which is the endpoint is an IPv6 address on the egress PE
loopback0. This same endpoint is used for all SR Algo’s as well and must
be routing reachable via the SRv6 forwarding plane. So technically for SR
policy using a static sid list could have a single Node SID or adjacency
SID in the middle of the path or could have endpoint SID or it could have
the endpoint SID plus the overlay service SID. What I have found with SRv6
compression with C-SID with Next-C-SID endpoint behavior using FD.IO VPP or
Linux kernel as the head node the Next SID carrier programming requires
both the endpoint SID and overlay service SID.
Based on what I have stated above the SR policy candidate path is steering
to the SR policy endpoint loopback0 and so both the endpoint SID and the
service SID are most definitely not required. So that should be included
as an option to exclude both the Node SID and overlay service SID.
As well processing both the Node SID and overlay SID endpoint behavior both
on the same node can be avoided by signaling PSP to POP the endpoint SID on
the PSP node so then both SIDs already have the capability of not being
processed on endpoint node egress PE if PSP is signaled.
I think this use case also definitively makes sense that I can think of is
if you have an Adj SID to the SR policy endpoint node you don’t need the
endpoint node SiD or overlay SID in the PCE computed segment list.
Also AFAIK EPE is not applicable to SRv6 since labels are not used and no
BGP-LU and no concept of LSP where all nodes must be SRv6 capable as any
vanilla IPv6 node can forward the SRv6 encapsulated packets. So you can
steer across any path of mix of capable and non capable nodes. EPE is for
the inter domain boundary where with MPLS you have BGP-LU for inter domain
stitching but now with SR-MPLS BGP-LU stitch is replaced with EPE to build
end to end LSP inter domain path. Not necessary for SRv6.
There was a similar situation where a SR architectural feature or
modification was brought up in PCE s and IDR and Ketan had given the
recommendation to first have a Spring related architecture draft and make
the draft only PCEP specific in PCE WG and BGP specific in IDR WG and not
related to any SR architecture modifications
https://datatracker.ietf.org/doc/draft-ietf-spring-pmtu-sr-policy/
I don’t this is a case necessarily but that situation with Linux kernel and
VPP requirements for endpoint SID and overlay service sid and now the
growing ecosystem with SRv6 it maybe good to run it by Spring.
I think it would be good to standardize and if Linux and VPP require this
then find out from the developers, find out why but technically I don’t see
why since static SID list does not require so PCE dynamic SID list should
not require.
The major use case here is with cloud native steering that if using F3216
format for Next SID and you only have 6 next sid 16 bit slots, if you can
save 2 Next SIDs slots in the next sid carrier both the endpoint sid and
service overlay sid you can steer a total of 6 hops not including the last
hop so a total of 7 hops really which is a massive optimization. So we
would have a bump of 2 extra hops end to end can steer a total of 7 hops
end to end without SRH which is quite incredible with F3216 next sid format.
I would recommend some of the updates I mentioned here for the draft as
well as adding in detailed comments on SRv6 compression next sid endpoint
behavior. Also mention replace sid as it can benefit as well even with SRH
if reduces size of SRH.
Great work on this draft!
Thanks
Gyan
On Fri, Nov 8, 2024 at 9:39 AM Zafar Ali (zali) <zali=
40cisco....@dmarc.ietf.org> wrote:
> Dear authors,
>
>
>
> We presented draft-ali-pce-srv6-policy-sid-list-optimization [1] and had
> some hallway discussions of the relationship of the sid-list optimization
> in OAM probes. Specifically, an SRv6 policy's SID list may end with the
> policy endpoint's node SID, and the traffic steered (over policy) already
> ensures that it is taken to the policy endpoint. In such cases, the SID
> list can be optimized by excluding the endpoint Node SID when installing
> the policy.
>
>
>
> It would be good to add considerations for this case in
> draft-ietf-spring-stamp-srpm.
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ali-pce-srv6-policy-sid-list-optimization/
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
> _______________________________________________
> spring mailing list -- spring@ietf.org
> To unsubscribe send an email to spring-le...@ietf.org
>
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
