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

Joel,

> 2019/10/18 1:14、Joel M. Halpern <jmh@joelhalpern.com>のメール:
> 
> 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.
> 

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

> 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
>>     >
>>     
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring