Re: [spring] Violation of the SRv6 architecture concern //RE: WGLC for draft-ietf-spring-sr-replication-segment

[James Guichard <[e-mail]>]

Hi Jingrong,

As stated in my previous email, let me once again draw your attention to the following text from RFC 8754:

4.3.1. <https://www.rfc-editor.org/rfc/rfc8754.html#section-4.3.1> FIB Entry Is a Locally Instantiated SRv6 SID<https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst>
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 the opinion of the chairs that this text explicitly provides the latitude to define a new SID and specify its behavior/s in a separate document, replacing all of the section 4.3.1.x text from RFC 8754. The fact that existing standardized behaviors follow a particular set of actions does not mean that a newly defined SID must also do so.

Thanks!

Jim, Joel & Bruno

From: Xiejingrong (Jingrong) <[e-mail]>
Sent: Monday, February 20, 2023 10:39 PM
To: James Guichard <[e-mail]>; Joel Halpern <[e-mail]>; [e-mail]
Cc: SPRING WG <[e-mail]>; [e-mail]
Subject: Violation of the SRv6 architecture concern //RE: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Jim, Joel & Bruno,

For the “Violation of the SRv6 architecture” concern, I have checked *all* the behaviors of SRv6 SID that is following with another SID:


l  End,

l  End.X,

l  End.T,

l  End.B6.Encaps,

l  End.B6.Encaps.Red,

l  End.BM

l  The SID defined in RFC 8754


I find that *all* of them are aligned with the meaning & semantics of SRv6/SRH/SID-list/Segment-Left:  process the next SID by updating the DA before submitting the packet to the IPv6 module. See below:


Example Pseudo-code of End SID (and also End.X, End.T):
S01. When an SRH is processed {
S12.   Decrement IPv6 Hop Limit by 1
S13.   Decrement Segments Left by 1
S14.   Update IPv6 DA with Segment List[Segments Left]
S15.   Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination
S16. }


Example Pseudo-code of End.B6.Encaps (and also End.B6.Encaps.Red, End.BM):
S01. When an SRH is processed {
S12.   Decrement IPv6 Hop Limit by 1
S13.   Decrement Segments Left by 1
S14.   Update IPv6 DA with Segment List[Segments Left]
S15.   Push a new IPv6 header with its own SRH containing B
S16.   Set the outer IPv6 SA to A
S17.   Set the outer IPv6 DA to the first SID of B
S18.   Set the outer Payload Length, Traffic Class, Flow Label,
          Hop Limit, and Next Header fields
S19.   Submit the packet to the egress IPv6 FIB lookup for
          transmission to the new destination
S20. }


Example Pseudo-code of “The SID defined in RFC8754” (which is a general example of processing by the meaning of SRv6/SRH/SID-List/Segment-Left) :
S01. When an SRH is processed {
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. }


Please allow me to list the main meaning & semantics of SRv6/SRH/SID-list/Segment-Left (below):
SRv6(8986): The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.
SRH(8754): Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH).
RH(8200): The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination.
Segment Left(8200): 8-bit unsigned integer.  Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination.


For Replication-SID with an SRv6 VPN SID after it, there is still  an SRv6 SID “to be visited” as the (Segment-Left==1) indicates, the behavior is not “processing” it but is overriding by the state of the Replication-SID.

SRv6 architecture, in my understanding, is built on the meaning & semantics of the above SRv6/SRH/RH/SID-list/Segment-Left, and has proven by *all* the SRv6 SID that is in RFC8754 & 8986.

That’s an additional argument for my concern about “Violation of the SRv6 architecture”.

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: James Guichard [mailto:[e-mail]]
Sent: Monday, February 20, 2023 11:30 PM
To: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>; Joel Halpern <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Jingrong,

Please see inline.

From: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 20, 2023 3:02 AM
To: James Guichard <[e-mail]<mailto:[e-mail]>>; Joel Halpern <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Jim, and WG chairs:

For Jim’s comment: ”[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.”

I think the sentence “Future documents may define additional SRv6 SIDs. In such a case, the entire content of this section will be defined in that document.” in 4.3.1 of RFC8754 does agree with that a Replication-SID can be defined in a document, but that does not mean that a Replication-SID defined in a document is technically correct.

[Jim] The above is helpful thank you.

Just in the same section, the following sentence is technical guideline of correctly using the SRH: “If the FIB entry represents a locally instantiated SRv6 SID, process the next header chain of the IPv6 header as defined in Section 4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8200%23section-4&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cc4895b0b01624760d03108db13bd273b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125475390816152%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mk0Xryp7oQ0pZJvEqsH%2Fqux%2FxRz4NrdpiFQg%2BFm9Bx8%3D&reserved=0> of [RFC8200<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8754.html%23RFC8200&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cc4895b0b01624760d03108db13bd273b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125475390816152%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BX5PA1EEpASoDzovI4p6gyBPfgoX16facPWfKyIGjpg%3D&reserved=0>]. Section 4.3.1.1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8754.html%23SRHPROC&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cc4895b0b01624760d03108db13bd273b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125475390816152%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=srl%2BfCD%2BHq9ZZiYqvm2%2FxXzwM%2BOApCHCH6sLRAZxxkU%3D&reserved=0> describes how to process an SRH; Section 4.3.1.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8754.html%23UPPERHEADER&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cc4895b0b01624760d03108db13bd273b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125475390972389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FZZB8ddxXkI8EtVhfb5%2Bjaz8PTJ%2BjEmw8vCSC7b7vXk%3D&reserved=0> describes how to process an upper-layer header or the absence of a Next Header.”

[Jim] You agree that RFC 8754 allows for new SIDs to be defined and that the operation of these SIDs should be defined in a new document. The wording that you have just agreed with specifically allows such new documents to define behaviors which do not agree with other sub-sections of RFC 8754 section 4.3.1. All of the concerns that you have expressed here cite elements of such sub-sections, thus the chairs do not agree with your concerns regarding violation of the SRv6 architecture. Respectively you failed to mention the previous sentence which says “In such a case, the entire content of this section will be defined in that document.” This means that the text you quote here does not apply as the entirety of section 4.3.1 is replaced by the new document. This is why the chairs have asked for the authors to expand their text to include pseudo-code that clearly defines the operation of a Replication SID.
[Jim] I have retained the remainder of your email for your context. If you have technical issues with the Replication SID specification itself we would like to understand those issues.

And please let me cite the pseudo-code of section 4.3.1.1 here below, and point out that, the normal behavior that implied in the meaning of SRv6/SID-List/SRH/Segment-Left, as shown in the S15/S16/S21/S22, is overridden by the state of Replication-SID, and hence breaking the SRv6 architecture.

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


To the chairs:


The authors had never answer my questions ( like “what is the 128bit DCB SRv6 SID looks like ?” in [4] and many others), but try to use such pieces of sentences to argue that the “VPN SID after Replication SID” is a valid solution.

I am very sad and worried about that.


To make my point clear, I had suggested in [A] that we have a comparative thinking like this:

What are the benefits of using SRH for VPN SID in multicast instead of using DOH ? ----DOH does not have the restriction in semantics of SRH/RH/SL that is conflicting.

What are the benefits of using SRH for VPN SID in multicast instead of using Src.DT4 as defined in [6] ? ----Src.DT4 does not have the restriction in semantics of SRH/RH/SL and  can save the encapsulation cost.

Let us think about it in another way ---- what is the implications of allowing an SRH SID-list to carry an identifier like SRv6 DCB SID?
----SRH would be abused to carry any information that is not an SRv6 SID in SID-List IMO.
----Even SRH TLV is more suitable for carrying such “Non SRv6 SID” thing than such an abuse of SID-List IMO, not to mention the above two alternatives (using DOH or Src.DT4).
----Once the abuse of SRH is made by the WGLC document, IMO it will not stop, by claiming the  correct use of “SRH”, or even claiming to be superior because of “using existing SRH data plane”.

[Jim] The chairs have already stated that details of VPN behavior will be dealt with in a separate document in an appropriate WG and are thus out of scope for this document.

Thanks!

Jim, Joel & Bruno

Is my point about “breaking SRv6 architecture” more clear by the above comparative thinking and the analysis of “implications” ?


Thanks,
Jingrong.


[A] https://mailarchive.ietf.org/arch/msg/spring/5iLxCBmOrSNqOafiCRYy3BZGvkg/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F5iLxCBmOrSNqOafiCRYy3BZGvkg%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7Cc4895b0b01624760d03108db13bd273b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125475390972389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JG0w3GV4IQmDJWPpdjFjts3VWHSrW1%2Fgk8uI%2FyAQ0%2Fc%3D&reserved=0>


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
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 James Guichard
Sent: Thursday, February 16, 2023 10:08 PM
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%7Cc4895b0b01624760d03108db13bd273b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125475390972389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eSYgDfFh%2Bn2CwLh3%2BuinNl4HU9TxhSO0IFq3grQznWg%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%7Cc4895b0b01624760d03108db13bd273b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638125475390972389%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i88T1u6k6e6meACXh9EvgoP9OoFm0yYAxa7dLmoTsXo%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”. 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

Furthermore, there is already precedence in SRv6 architecture to process an incoming packet based on local state and forward the modified packet. RFC 8986 defines End.B6.Encaps and End.B6.Encaps.Red (and End.BM) functions that rely on local SR policy state to modify an incoming packet.

Thanks,
-Rishabh