James, On Wed, Feb 15, 2023 at 8:05 AM James Guichard < james.n.guich...@futurewei.com> 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
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
