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

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

On 10/17/2019 12:09 PM, Pablo Camarillo (pcamaril) wrote:
> 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" <jmh@joelhalpern.com>
> Date: Thursday, 17 October 2019 at 15:26
> To: "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, "spring@ietf.org" <spring@ietf.org>
> Cc: draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
> Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
> Resent from: <alias-bounces@ietf.org>
> Resent to: <cf@cisco.com>, <pcamaril@cisco.com>, <john@leddy.net>, <daniel.voyer@bell.ca>, <satoru.matsushima@g.softbank.co.jp>, <lizhenbin@huawei.com>
> Resent date: Thursday, 17 October 2019 at 15:26
> 
>      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:
>      > 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 <li_zhenqiang@hotmail.com>
>      > *Date: *Thursday, 17 October 2019 at 06:11
>      > *To: *"Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, Ron Bonica
>      > <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>
>      > *Cc: *draft-ietf-spring-srv6-network-programming
>      > <draft-ietf-spring-srv6-network-programming@ietf.org>
>      > *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
>      >
>      > ------------------------------------------------------------------------
>      >
>      > li_zhenqiang@hotmail.com
>      >
>      >     *From:*Pablo Camarillo (pcamaril) <mailto:pcamaril@cisco.com>
>      >
>      >     *Date:* 2019-10-16 00:45
>      >
>      >     *To:*li zhenqiang <mailto:li_zhenqiang@hotmail.com>; Ron Bonica
>      >     <mailto:rbonica=40juniper.net@dmarc.ietf.org>; spring@ietf.org
>      >     <mailto:spring@ietf.org>
>      >
>      >     *CC:*draft-ietf-spring-srv6-network-programming
>      >     <mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
>      >
>      >     *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 <li_zhenqiang@hotmail.com>
>      >     *Date: *Tuesday, 15 October 2019 at 09:32
>      >     *To: *Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>,
>      >     "spring@ietf.org" <spring@ietf.org>
>      >     *Cc: *draft-ietf-spring-srv6-network-programming
>      >     <draft-ietf-spring-srv6-network-programming@ietf.org>
>      >     *Subject: *Re: [spring] draft-ietf-spring-srv6-network-programming:
>      >     Section 4.16
>      >     *Resent from: *<alias-bounces@ietf.org>
>      >     *Resent to: *<cf@cisco.com>, <pcamaril@cisco.com>, <john@leddy.net>,
>      >     <daniel.voyer@bell.ca>, <satoru.matsushima@g.softbank.co.jp>,
>      >     <lizhenbin@huawei.com>
>      >     *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
>      >
>      >     ------------------------------------------------------------------------
>      >
>      >     li_zhenqiang@hotmail.com
>      >
>      >         *From:*Ron Bonica <mailto:rbonica=40juniper.net@dmarc.ietf.org>
>      >
>      >         *Date:* 2019-10-15 02:42
>      >
>      >         *To:*SPRING WG List <mailto:spring@ietf.org>
>      >
>      >         *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
>      >
>      >
>      > _______________________________________________
>      > spring mailing list
>      > spring@ietf.org
>      > https://www.ietf.org/mailman/listinfo/spring
>      >
>      
> 