Hi Rishabh,
Just to be clear, I do not expect you to document how TLVs are to be processed
just simply wording like 8754 and where in the logic that should happen:
S06. If local configuration requires TLV processing {
S07. Perform TLV processing (see TLV Processing)
Jim
From: Rishabh Parekh <[email protected]>
Sent: Tuesday, February 28, 2023 4:52 PM
To: James Guichard <[email protected]>
Cc: SPRING WG List <[email protected]>; [email protected]
Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment
Jim,
Fine. Will add SRH TLV processing to pseudo-code in next revision.
-Rishabh
On Tue, Feb 28, 2023 at 1:49 PM James Guichard
<[email protected]<mailto:[email protected]>> wrote:
Hi Rishabh,
Thanks. Adding where in the processing logic TLVs are processed (if locally
configured) I think is a worthwhile update.
Jim
From: Rishabh Parekh <[email protected]<mailto:[email protected]>>
Sent: Tuesday, February 28, 2023 4:48 PM
To: James Guichard
<[email protected]<mailto:[email protected]>>
Cc: SPRING WG List <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment
Jim,
Thanks for diligently catching the typos in the document :) Will fix them in
the next revision.
As for SRH TLVs, they can be processed at Replication Node, if allowed by local
configuration, before an incoming packet is replicated. I see RFC 8754 Section
4.3.1.1 SRH processing pseudo-code does not explicitly mention SRH TLV
processing, but we can add to SRv6 End.Replication pseudo-code if you think it
is necessary.
Thanks,
-Rishabh
On Tue, Feb 28, 2023 at 6:11 AM James Guichard
<[email protected]<mailto:[email protected]>> wrote:
Hi Rishabh,
Thank you for the new version. A few nits/comments:
* Text in the abstract currently says "A SR Replication segment allows a
packet to be replicated from a Replication Node to Downstream nodes".
* Perhaps change to -> ""A SR Replication segment allows a packet to be
replicated from a Replication Node to one or more Downstream nodes".
* Couple of typos in the Introduction:
* Replication segment is a new type of segment for Segment Routing
[RFC8402], which allows a node (henceforth called as Replication
* [Jim] r/as/a
* A Replication segment can replicate packet to directly connected nodes or
to downstream nodes
* [Jim] r/packet/packets
* Section 2.2.1
* [Jim] I do not see any mention of TLV processing. If local
configuration requires TLV processing where in the pseudo code does this fit?
Are there circumstances where TLV processing is prohibited if using a
Replication SID? Please add this.
* Section 2.2.1
* * The behavior above MAY result in a packet with partially processed
segment list in SRH under some circumstances
* [Jim] It would be helpful to provide an example of such a
circumstance here.
* Section 2.2.2
* the Leaf/Bud bud node which responds with an ICMPv6 Echo
* [Jim] remove "bud" typo
Thanks!
Jim
From: Rishabh Parekh <[email protected]<mailto:[email protected]>>
Sent: Monday, February 27, 2023 2:57 PM
To: SPRING WG List <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment
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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Sent: Thursday, February 16, 2023 12:37 AM
To: James Guichard
<[email protected]<mailto:[email protected]>>
Cc: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; SPRING WG
<[email protected]<mailto:[email protected]>>
Subject: Re: WGLC for draft-ietf-spring-sr-replication-segment
James,
On Wed, Feb 15, 2023 at 8:05 AM James Guichard
<[email protected]<mailto:[email protected]>> 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%7Cbd764b44333a483da75c08db19d5fba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638132179072650119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vK%2B9hJInHUqCMtIdcCJe2yWTDV18H%2Fyu2JkOmaDqazg%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%7Cbd764b44333a483da75c08db19d5fba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638132179072650119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=scAoe9b6OAO1skrgsmO1oNfcylVOpvM62mDT2afTKTg%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%7Cbd764b44333a483da75c08db19d5fba3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638132179072650119%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vK%2B9hJInHUqCMtIdcCJe2yWTDV18H%2Fyu2JkOmaDqazg%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
[email protected]
https://www.ietf.org/mailman/listinfo/spring
