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

[Rishabh Parekh <[e-mail]>]

We have published revision 12 of the draft. Main changes include:
- Pseudo-code for SRv6 End.Replicate
- Description and example of ping to a Replication SID
- Changes to text to address comments from Bruno, Jim and Joel

Please review.

Thanks,
-Rishabh

On Fri, Feb 24, 2023 at 4:06 PM Rishabh Parekh <[e-mail]> wrote:

> Jim,
> The text you refer to in Section 2.1 and .2.2 has changed after addressing
> comments since the last revision, but we will try to incorporate the
> suggested change.
>
> Thanks,
> -Rishabh
>
> On Mon, Feb 20, 2023 at 8:06 AM James Guichard <
> [e-mail]> wrote:
>
>> Hi Rishabh & authors,
>>
>> To close out this discussion, in sections 2.1 and 2.2 we have:
>>
>> There MAY be SIDs after the Replication SID in the segment list of a
>> packet. These SIDs are used to provide additional context for processing a
>> packet locally at the node where the Replication SID is the Active Segment.
>> The processing of SIDs following the Replication SID MUST NOT forward the
>> SR-MPLS packet to another node.
>>
>>
>>
>> The chairs believe it would be helpful to add a sentence to clarity the
>> scope and offer the following text "Coordination regarding the absence or
>> presence and value of context information for replication leaves is outside
>> the scope of this document.".
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Jim, Joel & Bruno
>>
>>
>>
>>
>>
>> *From:* Rishabh Parekh <[e-mail]>
>> *Sent:* Thursday, February 16, 2023 12:37 AM
>> *To:* James Guichard <[e-mail]>
>> *Cc:* Xiejingrong (Jingrong) <xiejingrong=[e-mail]>;
>> [e-mail]; SPRING WG <[e-mail]>
>> *Subject:* Re: WGLC for draft-ietf-spring-sr-replication-segment
>>
>>
>>
>> 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%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xMx%2BHL31Nq%2FdqZZOXZf9ZEkPD5dptGq7Tsdp7mwieiU%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
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8754.html%23name-fib-entry-is-a-locally-inst&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q56RV5lZ8B6B%2F43YzGfa1LyhHu3l1JZbK9M%2Byx3hDvk%3D&reserved=0>
>> 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%7Cdb56daac0d014f3482a208db0fdfde76%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121226437340003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xMx%2BHL31Nq%2FdqZZOXZf9ZEkPD5dptGq7Tsdp7mwieiU%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
>>
>>
>>
>>
>>
>