Jim,
In addition to RFC 8754 Section 4.3.1, the following text from RFC 8986
Section 4 also supports the claim the Replication SID is valid within SRv6
architecture.
The list is not exhaustive. In practice, any behavior can be attached to a
local SID; for example, a node N can bind a SID to a local Virtual Machine
(VM) or container that can apply any complex processing on the packet,
provided there is an SRv6 Endpoint Behavior codepoint allocated for the
processing.
As per your request, we are planning to add the following text for
pseudo-code of Replication SID:.
The "Endpoint with replication and/or decapsulate behavior (End.Replicate
for short) is a variant of End behavior.
A Replication State conceptually contains following elements:
Replication State:
{
Node-Role: {Head, Transit, Leaf, Bud};
# On Leaf, replication list is zero length
Replication-List:
{
Downstream Node: <Node-Identifier>;
Downstream Replication SID: R-SID;
# Segment-List maybe be empty
Segment-List: [SID-1, .... SID-N];
}
}
Below is the Replicate function on a packet for Replication State (RS).
S01. Replicate(RS, packet)
S02. {
S03. For each Replication R in RS.Replication-List {
S04. Make a copy of the packet
S05. Set IPv6 DA = RS.R-SID
S06. If RS.Segment-List is not empty {
S07. # Head node MAY optimize below encap and encap of packet
in a single encap
S08. Execute H.Encaps or H.Encaps.Red with RS.Segment-List on
packet copy #RFC 8986 Section 5.1, 5.2
S09 }
S10. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination
S11. }
S12. }
Note:
When N receives a packet whose IPv6 DA is S and S is a local End.Replicate
SID, N does:
S01. Lookup FUNCT portion of S to get Replication State RS
S02. If (IPv6 Hop Limit <= 1) {
S03. Discard the packet
S04. # ICMP Time Exceeded is not permitted (Section 2.2.3 below)
S05. }
S06. If RS is not found {
S07. Discard the packet
S08. }
S09. Decrement IPv6 Hop Limit by 1
S10. Call Replicate(RS, packet)
S11. If (RS.Node-Role == Leaf or RS.Node-Role == Bud) {
S12. If (IPv6 NH == SRH and Segments Left > 0) {
S13. Derive packet processing context(PPC) from Segment
List[Segments Left - 1]
S14. } Else {
S15. Derive packet processing context(PPC) from FUNCT of Replication SID
S16. }
S17. Remove the outer IPv6 header with all its extension headers
S18. Process the packet in context of PPC
S19. }
Notes:
The packet processing context usually is a FIB table T
- The IPv6 destination address in the copy of a packet is set from local
state and not from SRH
- The behavior above MAY result in a packet with partially processed
segment list in SRH under some circumstances
Thanks,
-Rishabh
On Thu, Feb 16, 2023 at 6:13 AM James Guichard <
james.n.guich...@futurewei.com> wrote:
> Hi Rishabh,
>
>
>
> For some unknown reason my full responses were truncated. Here is the full
> response:
>
>
>
> Hi Rishabh, Authors, & WG:
>
> Having reviewed the latest version of
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-replication-segment%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cbdcb0e652a84487b56d008db0fdedb81%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638121222064204376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jc%2FjseIG6xUGJ37UWvP0x8QYl027YZMOojcWM7pbt%2BA%3D&reserved=0>
> I would appreciate some clarification from the authors on the specifics of
> packet replication and forwarding between the replication point and
> downstream nodes. The draft as I read it bases forwarding at a replication
> point on the combination of a replication SID which triggers and selects
> the behavior and the replication state held at that node. The replication
> state indicates which downstream nodes the packet should be replicated to
> and those nodes may or may not be adjacent to the replication node. In the
> non-adjacent case my understanding is that the replication state may
> include an additional segment-list and this seems to be what the text in
> section 2.2. is saying by referencing H.Encaps.Red to re-encapsulate the
> packet with a new SRH and outer IPv6 header. If this is correct could it be
> made more explicit; at a minimum I would expect to see a reference to RFC
> 8986 section 5.2.
>
> [RP] Your understanding is correct. We can add a reference to RFC 8986
> Section 5.2 as you suggest, but you say "... could it be made more explicit
> ..". Do you mean the current text is not clear about this?
>
>
>
> [Jim] thank you the addition of the reference is helpful.
>
> [Jim] I think the document could be more explicit by adding pseudo-code
> which shows the actual processing logic of the newly defined SID. RFC 8754
> section 4.3.1 is very clear on this point. Please review
> https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst
> You will see that the RFC says “This document and section define a single
> SRv6 SID. *Future documents may define additional SRv6 SIDs. *In such a
> case, the *entire content of this section will be defined in that
> document”. *It is clear that your document is defining a new SID, the
> Replication SID, and the processing logic of that SID is different to the
> SRv6 SID as defined in RFC 8754. Showing in your document the processing
> logic pseudo-code will make this clearer and will also follow the
> guidelines from RFC 8754.
>
> In addition to this I would like to clarify the case where
> re-encapsulation is not needed i.e. when an explicit path to a downstream
> node is not necessary and best path forwarding suffices. The text says that
> in this case the outer IPv6 header is re-used and the downstream
> replication SID is written into the IPv6 header destination address. This
> address is most likely NOT contained within the SRH which is a detachment
> from the normal SRv6 forwarding case and I would like to hear the authors
> and WGs opinions on this.
>
> [RP] Yes, an encapsulation is not needed when a Downstream node is
> adjacent or best path forwarding to a non-adjacent node is sufficient. The
> downstream node's Replication SID (from Replication State) is written in
> outer IPv6 DA and packet is forwarded based on the locator of the
> downstream node. Our (i.e. authors) opinion is that is permissible within
> the SRv6 architecture by new End.Replication behavior (associated with
> incoming local Replication SID) defined in the draft.
>
>
>
> [Jim] Section 4.3.1 of RFC 8754 would appear to agree with you but I
> welcome the WGs comments on this if there is disagreement.
>
>
>
> Jim
>
>
>
>
>
> *From:* James Guichard <james.n.guich...@futurewei.com>
> *Sent:* Thursday, February 16, 2023 9:08 AM
> *To:* Rishabh Parekh <risha...@gmail.com>
> *Cc:* bruno.decra...@orange.com; SPRING WG <spring@ietf.org>;
> spring-cha...@ietf.org
> *Subject:* RE: [spring] WGLC for draft-ietf-spring-sr-replication-segment
>
>
>
> Hi Rishabh,
>
>
>
> Please see inline [Jim]
>
>
>
> On Wed, Feb 15, 2023 at 6:58 AM James Guichard <
> james.n.guich...@futurewei.com> wrote:
>
> Hi Rishabh, Authors, & WG:
>
>
>
> Having reviewed the latest version of
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-replication-segment%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C2ea8225a08d44d397ee608db102731ef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638121532773142557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=lg6oJOvBVIhGromWSDygAWNqZfrafgMMiTVGasfE1Bo%3D&reserved=0>
> I would appreciate some clarification from the authors on the specifics of
> packet replication and forwarding between the replication point and
> downstream nodes. The draft as I read it bases forwarding at a replication
> point on the combination of a replication SID which triggers and selects
> the behavior and the replication state held at that node. The replication
> state indicates which downstream nodes the packet should be replicated to
> and those nodes may or may not be adjacent to the replication node. In the
> non-adjacent case my understanding is that the replication state may
> include an additional segment-list and this seems to be what the text in
> section 2.2. is saying by referencing H.Encaps.Red to re-encapsulate the
> packet with a new SRH and outer IPv6 header. If this is correct could it be
> made more explicit; at a minimum I would expect to see a reference to RFC
> 8986 section 5.2.
>
>
>
> [RP] Your understanding is correct. We can add a reference to RFC 8986
> Section 5.2 as you suggest, but you say "... could it be made more explicit
> ..". Do you mean the current text is not clear about this?
>
>
>
> [Jim] thank you the addition of the reference is helpful.
>
> [Jim] I think the document could be more explicit by adding pseudo-code
> which shows the actual processing logic of the newly defined SID. RFC 8754
> section 4.3.1 is very clear on this point. Please review
> 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%7C2ea8225a08d44d397ee608db102731ef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C638121532773142557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=%2FVxeUN7BrqruNTpy%2BOTI6JupIuLam%2FjB9elmS3M%2B%2BHQ%3D&reserved=0>
> You will see that the RFC says “This document and section define a single
> SRv6 SID. *Future documents may define additional SRv6 SIDs. *In such a
> case, the *entire content of this section will be defined in that
> document”*
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
