Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

[Rishabh Parekh <[e-mail]>]

James,

On Wed, Feb 15, 2023 at 8:05 AM James Guichard <
[e-mail]> wrote:

> Hi Jingrong & document authors,
>
>
>
> I would like for now to leave aside the issue of whether or not
> application/VPN specifics should be outside the scope of this SPRING
> document (I will however be revisiting this point in subsequent emails) and
> focus on bringing closure to the technical comments detailed in
> https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%3D&reserved=0>
> .
>
>
>
> As I read through your comments Jingrong I think I can summarize your
> objection to be that you believe the proposal breaks the SRv6 architecture
> as the forwarding relies upon local state rather than state carried within
> the SRH. Do I have that right? If this is the case then you need to be
> specific in terms of which text/sentences in the document are in conflict
> with which text/sentences of existing RFCs. As written I think Rishabh’s
> forwarding example is accurate as he describes a lookup on the Replication
> SID and the action is to either update the outer IPv6 address with the
> downstream nodes address, or re-encapsulate the packet with a new IPv6
> header and SRH. I might draw your attention to
> https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst
> which talks about the definition of future SIDs and their behaviors.
>
>
>
> Further your comments appear to me to suggest that the VPN identification
> encapsulated at PE1 acts like a normal VPN SID in the sense that forwarding
> is based upon that IPv6 address. I don’t think that is the intent here; I
> think the SID is used as an identifier for the VPN itself so that the
> downstream nodes are given the correct VPN forwarding context i.e. they are
> not supposed to use that SID to forward the packets back to PE1. Perhaps
> the authors could clarify this point further?
>

>
> Hi Rishabh, it would be helpful if you could review the comments in
> https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%3D&reserved=0> again
> and perhaps provide more clarity on the expected behavior as there seems to
> be a difference in understanding of the actual operation.
>

[RP] Exactly, the only purpose of VPN SID is to provide a VPN context at
Leaf/Bud nodes to forward the inner packet (encapsulated at ingress PE).  I
have removed most of the text related to VPN (in yet unpublished next
revision) based on Bruno's earlier, but this has been explained earlier in
the thread.

-Rishabh