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

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Authors,



Do you have a timeline in mind to address my questions in the following [1] [3] [4] [8b]  that are still pending before you write a new Pseudo-code ?



[1] https://mailarchive.ietf.org/arch/msg/spring/659RqpS2eOabwBpist6iH6nGgrw/

[2] https://mailarchive.ietf.org/arch/msg/spring/zo41ZDrH2Nq_xishIOly8ga19Ns/

[3] https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/

[4] https://mailarchive.ietf.org/arch/msg/spring/ou0V6vmWm4hlAk4I9Cuad1QXzIo/

[5] https://mailarchive.ietf.org/arch/msg/spring/DygdlzN2PiyXkN8RKjy3mb53mYE/

[6] https://datatracker.ietf.org/doc/html/draft-xie-bier-ipv6-mvpn-01

[7] https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-06
[8] 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>
[8b] https://mailarchive.ietf.org/arch/msg/spring/x49aMfShzK_mM3wf8_FRLoRgZYo/
[9] https://mailarchive.ietf.org/arch/msg/spring/FyoRJdW2fMx1yVid0ddl8Pz4QeY/





I have browsed the pseudo-code roughly, and I see it is demonstrating my concern about “breaking SRv6 architecture by overriding behavior(s) caused by the state of Replication SID” is valid.

E.g., The following pseudo-code shows clearly that, the State of Replication SID (S11) is overriding the behaviors that an SRv6 architecture should do by the meaning of  (SRv6/SRH/SID-list/SL), hence breaking the SRv6 architecture.



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.   }





The behavior(s) that the SRv6 architecture(SRH/SID-list/SL) should do, by the meaning of  (SRv6/SRH/SID-list/SL),  as I mentioned in previous mail, are very well illustrated in the pseudo-code (Step S15/S16/S21/S22) of https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst :
S01. When an SRH is processed {
S02.   If Segments Left is equal to zero {
S03.     Proceed to process the next header in the packet,
         whose type is identified by the Next Header field in
         the routing header.
S04.   }
S05.   Else {
S06.     If local configuration requires TLV processing {
S07.       Perform TLV processing (see TLV Processing)
S08.     }
S09.     max_last_entry  =  ( Hdr Ext Len /  2 ) - 1
S10.     If  ((Last Entry > max_last_entry) or
S11.          (Segments Left is greater than (Last Entry+1)) {
S12.       Send an ICMP Parameter Problem, Code 0, message to
           the Source Address, pointing to the Segments Left
           field, and discard the packet.
S13.     }
S14.     Else {
S15.       Decrement Segments Left by 1.
S16.       Copy Segment List[Segments Left] from the SRH to the
           destination address of the IPv6 header.
S17.       If the IPv6 Hop Limit is less than or equal to 1 {
S18.         Send an ICMP Time Exceeded -- Hop Limit Exceeded in
             Transit message to the Source Address and discard
             the packet.
S19.       }
S20.       Else {
S21.         Decrement the Hop Limit by 1
S22.         Resubmit the packet to the IPv6 module for transmission
             to the new destination.
S23.       }
S24.     }
S25.   }
S26. }





Thanks,

Jingrong


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments may contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: spring [mailto:[e-mail]] On Behalf Of Rishabh Parekh
Sent: Saturday, February 18, 2023 8:12 AM
To: James Guichard <[e-mail]>
Cc: [e-mail]; SPRING WG <[e-mail]>
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, February 16, 2023 9:08 AM
To: Rishabh Parekh <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; SPRING WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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”