Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 17 Oct 2019 09:41:17 +0000

Li,

   Node1's
   Tenant-100 IPv4 table is: T.Encaps with SRv6 Policy <B:3:C4::,
   B:8:D100::>.

   When 1 receives a packet P from CE-A destined to 20.20.20.20, P looks
   up its tenant-100 IPv4 table and finds an SR-VPN entry 20/8.  As a
   consequence, 1 pushes an outer header with SA=A:1::, DA=B:3:C4::,
   NH=SRH followed by SRH (B:8:D100::, B:3:C4::; SL=1; NH=4). 1 then
   forwards the resulting packet on the interface to 2.

   2 forwards to 3 along the path to B:3::/32.

   When 3 receives the packet, 3 matches the DA in its "My SID Table"
   and finds the bound function End.X to neighbor 4. 3 notes the PSP
   capability of the SID B:3:C4::. 3 sets the DA to the next SID
   B:8:D100::. As 3 is the penultimate segment hop, it performs PSP and
   pops the SRH. 3 forwards the resulting packet to 4.

   4, 6 and 7 forwards along the path to B:8::/32.

  When 8 receives the packet, 8 matches the DA in its "My SID Table"
   and finds the bound function End.DT(100).  As a result, 8 decaps the
   outer header, looks up the inner IPv4 DA (20.20.20.20) in tenant-100
   IPv4 table, and forward the (inner) IPv4 packet towards CE-B.

Node 3 receives the packet SA=A:1::, DA=B:3:C4::,NH=SRH followed by SRH (B:8:D100::, B:3:C4::; SL=1; NH=4)
The SID B:3:C4:: is associated with the End.X behavior with PSP support. Node 3 is going to decrement SL, copy the segment B:8:D100:: into the IPv6 DA and set the packet’s egress adjacency to J (adjacency associated with that SID instance). Additionally, (PSP) it will check what is the SL value in the SRH. If the SL=0 it will remove the SRH from the packet.

The segment B:3:C4:: is the penultimate SID in the segment list <B:3:C4::, B:8:D100::>. Note that the PSP behavior is not related to IP hops.

Cheers,
Pablo.

From: li zhenqiang <[email-masked]>
Date: Thursday, 17 October 2019 at 06:11
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16

Hi Pablo,

I am still confused by the example in section 2.8.1. Node 3 is the destionation of SID B:3:C4::, why should it behave PSP for this SID? While for SID B:8:D100::, it is an END.DT4, the PSP behavior is not defined for this kind of SIDs. Node 3 should not behave PSP for SID B:8:D100::, neither.  Would you please explain node 3 is the penultimate segment hop of which node or which segment? Suppose the behavior is correct, may I know the benifit you gain in this example?

Many Thanks,
Zhenqiang Li
________________________________
[email-masked]

From: Pablo Camarillo (pcamaril)<mailto:[email-masked]>
Date: 2019-10-16 00:45
To: li zhenqiang<mailto:[email-masked]>; Ron Bonica<mailto:rbonica=[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
Li,

I have replied the technical questions regarding PSP and USP in the email thread from one week ago.
You have not provided any technical concern.

> “Further, the example for PSP in the companion doc srv6-net-pgm-illustration is wrong. PSP is used for END.DT4 in the companion doc while flavors are only defined for END, END.X and END.T in srv6-network-programming.”

The illustration in section 2.8.1 is correct. Please re-read it. PSP is used at node 3 together with the End.X behavior.

Regards,
Pablo.

Replies from one week ago:
https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c
https://mailarchive.ietf.org/arch/msg/spring/WrYzRZC0HKVgBYaYMCQVcTWrfak

From: li zhenqiang <[email-masked]>
Date: Tuesday, 15 October 2019 at 09:32
To: Ron Bonica <rbonica=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Tuesday, 15 October 2019 at 09:32

I suggest this section be removed from this version until the community reaches rough consensus.
Further, the example for PSP in the companion doc srv6-net-pgm-illustration is wrong. PSP is used for END.DT4 in the companion doc while flavors are only defined for END, END.X and END.T in srv6-network-programming.

Best Regards,
Zhenqiang Li
________________________________
[email-masked]

From: Ron Bonica<mailto:rbonica=[email-masked]>
Date: 2019-10-15 02:42
To: SPRING WG List<mailto:[email-masked]>
Subject: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
Authors,

Lacking the B.INSERT and T.INSERT functions, can you describe a use-case for the PSP and USP flavors of the END, END.X and END.T functions?

                                              Ron

Juniper Business Use Only

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Oct 2019 09:26:08 -0400

Removing a header from an IPv6 packet (without removing the whole IPv6 
header) is a violation of RFC 8200.

As such, it should be removed from the base network programming draft. 
If you really want it, put it in the new insertion draft.  And justify it.

With regard to the example of off-load, the usual practice has been to 
avoid standardizing off-load behaviors in the IETF.  the NIC vendors 
come up with all sorts of ways to improve performance that violate the 
specifications.  We do not endorse that, and leave the need for 
consenting devices engaging in proprietary communication to them.

Yours,
Joel

On 10/17/2019 5:41 AM, Pablo Camarillo (pcamaril) wrote:
> The SID B:3:C4:: is associated with the End.X behavior with PSP support. 
> Node 3 is going to decrement SL, copy the segment B:8:D100:: into the 
> IPv6 DA and set the packet’s egress adjacency to J (adjacency associated 
> with that SID instance). Additionally, (PSP) it will check what is the 
> SL value in the SRH. If the SL=0 it will remove the SRH from the packet.
> 
> The segment B:3:C4:: is the penultimate SID in the segment list 
> <B:3:C4::, B:8:D100::>. Note that the PSP behavior is not related to IP 
> hops.
> 
> Cheers,
> 
> Pablo.
> 
> *From: *li zhenqiang <[email-masked]>
> *Date: *Thursday, 17 October 2019 at 06:11
> *To: *"Pablo Camarillo (pcamaril)" <[email-masked]>, Ron Bonica 
> <rbonica=[email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *draft-ietf-spring-srv6-network-programming 
> <[email-masked]>
> *Subject: *Re: Re: [spring] draft-ietf-spring-srv6-network-programming: 
> Section 4.16
> 
> Hi Pablo,
> 
> I am still confused by the example in section 2.8.1. Node 3 is the 
> destionation of SID B:3:C4::, why should it behave PSP for this SID? 
> While for SID B:8:D100::, it is an END.DT4, the PSP behavior is not 
> defined for this kind of SIDs. Node 3 should not behave PSP for SID 
> B:8:D100::, neither.  Would you please explain node 3 is the penultimate 
> segment hop of which node or which segment? Suppose the behavior is 
> correct, may I know the benifit you gain in this example?
> 
> Many Thanks,
> 
> Zhenqiang Li
> 
> ------------------------------------------------------------------------
> 
> [email-masked]
> 
>     *From:*Pablo Camarillo (pcamaril) <mailto:[email-masked]>
> 
>     *Date:* 2019-10-16 00:45
> 
>     *To:*li zhenqiang <mailto:[email-masked]>; Ron Bonica
>     <mailto:rbonica=[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
> 
>     *CC:*draft-ietf-spring-srv6-network-programming
>     <mailto:[email-masked]>
> 
>     *Subject:* Re: [spring] draft-ietf-spring-srv6-network-programming:
>     Section 4.16
> 
>     Li,
> 
>     The illustration in section 2.8.1 is correct. Please re-read it. PSP
>     is used at node 3 together with the End.X behavior.
> 
>     Regards,
> 
>     Pablo.
> 
>     *From: *li zhenqiang <[email-masked]>
>     *Date: *Tuesday, 15 October 2019 at 09:32
>     *To: *Ron Bonica <rbonica=[email-masked]>,
>     "[email-masked]" <[email-masked]>
>     *Cc: *draft-ietf-spring-srv6-network-programming
>     <[email-masked]>
>     *Subject: *Re: [spring] draft-ietf-spring-srv6-network-programming:
>     Section 4.16
>     *Resent from: *<[email-masked]>
>     *Resent to: *<[email-masked]>, <[email-masked]>, <[email-masked]>,
>     <[email-masked]>, <[email-masked]>,
>     <[email-masked]>
>     *Resent date: *Tuesday, 15 October 2019 at 09:32
> 
>     Further, the example for PSP in the companion doc
>     srv6-net-pgm-illustration is wrong. PSP is used for END.DT4 in the
>     companion doc while flavors are only defined for END, END.X and
>     END.T in srv6-network-programming.
> 
>     Best Regards,
> 
>     Zhenqiang Li
> 
>     ------------------------------------------------------------------------
> 
>     [email-masked]
> 
>         *From:*Ron Bonica <mailto:rbonica=[email-masked]>
> 
>         *Date:* 2019-10-15 02:42
> 
>         *To:*SPRING WG List <mailto:[email-masked]>
> 
>         *Subject:* [spring] draft-ietf-spring-srv6-network-programming:
>         Section 4.16
> 
>         Authors,
> 
>         Lacking the B.INSERT and T.INSERT functions, can you describe a
>         use-case for the PSP and USP flavors of the END, END.X and END.T
>         functions?
> 
>         Ron
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 17 Oct 2019 16:09:22 +0000

Hi Joel, 

RFC8200 permits extension header processing, insertion, deletion at a node identified in the Destination Address field of the IPv6 header. This has been discussed in other threads like https://mailarchive.ietf.org/arch/msg/ipv6/Ypnpw-oneCb7W6s41dVZGMok0Nw .

Thanks,
Pablo

-----Original Message-----
From: "Joel M. Halpern" <[email-masked]>
Date: Thursday, 17 October 2019 at 15:26
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Thursday, 17 October 2019 at 15:26

    
    
    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Oct 2019 12:14:13 -0400

Pretending it is legitimate, let me ask a different aspect of the question.

Removing bytes (aor adding bytes) from arbitrary positions in the middle 
of a packet is generally any extremely painful operation.  Why would we 
want a standard that mandated such an operation?  Savings a few bytes on 
SR hop (sure, several IP router hops) seems a small benefit for such a cost.

Yours,
Joel

---

From: li zhenqiang <[email-masked]>
Date: Fri, 18 Oct 2019 02:50:34 +0000

Hi Joel and Pablo,

I also argued the benefits for the flavors and suggested the flavor section be removed from current version and may be discussed in a seperate document.
Even this section can be retained after discussion,  I think at least some justifications are needed since srv6-network-programming is our SRv6 base specification and the flavors are first introduced in SRv6.
The meaning or semantic of each flavor needs more explaination according to our discussion to remove the ambiguity in understanding.

Thank you very much for all the authors' kind consideration for my friendly suggestion.

Best Regards,
Zhenqiang Li

From: Joel M. Halpern<mailto:[email-masked]>
Date: 2019-10-18 00:14
To: Pablo Camarillo (pcamaril)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
CC: draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
Pretending it is legitimate, let me ask a different aspect of the question.

Yours,
Joel

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 18 Oct 2019 02:58:35 +0000

Hi Zhenqiang and Jeol,

As my understanding,  the problem is clear.

the PSP flavor is associated with the penultimate SID in the segment list, which may be an END, END.X or END.T. 

The PSP action will be executed after the last SID, which can be an END.Dx SID, is updated to the IPv6 DA.

For instance, the PSP action is executed on the node C according to an END.X SID with PSP flavor initiated by it, and the updated IPv6 DA is an END.DT4 SID.

A----B---C-----D

Now the questions are,
1. do we need this flavor? 
2. what is the benefit?
3. what is the pain of removing the SRH without removing the whole IPv6 header?  I think we need some explanations on the word "extremely painful".

Use cases are needed.

Cheng

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, October 18, 2019 12:14 AM
To: Pablo Camarillo (pcamaril) <[email-masked]>; [email-masked]
Cc: draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16

Removing bytes (aor adding bytes) from arbitrary positions in the middle of a packet is generally any extremely painful operation.  Why would we want a standard that mandated such an operation?  Savings a few bytes on SR hop (sure, several IP router hops) seems a small benefit for such a cost.

Yours,
Joel

On 10/17/2019 12:09 PM, Pablo Camarillo (pcamaril) wrote:
> Cc: draft-ietf-spring-srv6-network-programming 
> Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: 
> Section 4.16 Resent from: <[email-masked]> Resent to: 
> <[email-masked]>, <[email-masked]>, <[email-masked]>, 
> <[email-masked]> Resent date: Thursday, 17 October 2019 at 15:26
>

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 18 Oct 2019 14:05:21 +0900

Joel,

> 2019/10/18 1:14、Joel M. Halpern <[email-masked]>のメール:
> 

That sounds weird comment for me. We have deployed that type of function with no compromise in terms of of both performance and operation within reasonable and affordable cost.

Cheers,
--satoru