Joel, > 2019/10/18 1:14、Joel M. Halpern <[email protected]>のメール: > > 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" <[email protected]> >> Date: Thursday, 17 October 2019 at 15:26 >> To: "Pablo Camarillo (pcamaril)" <[email protected]>, "[email protected]" >> <[email protected]> >> Cc: draft-ietf-spring-srv6-network-programming >> <[email protected]> >> Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section >> 4.16 >> Resent from: <[email protected]> >> Resent to: <[email protected]>, <[email protected]>, <[email protected]>, >> <[email protected]>, <[email protected]>, >> <[email protected]> >> 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 <[email protected]> >> > *Date: *Thursday, 17 October 2019 at 06:11 >> > *To: *"Pablo Camarillo (pcamaril)" <[email protected]>, Ron Bonica >> > <[email protected]>, "[email protected]" >> <[email protected]> >> > *Cc: *draft-ietf-spring-srv6-network-programming >> > <[email protected]> >> > *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 protected] >> > >> > *From:*Pablo Camarillo (pcamaril) <mailto:[email protected]> >> > >> > *Date:* 2019-10-16 00:45 >> > >> > *To:*li zhenqiang <mailto:[email protected]>; Ron Bonica >> > <mailto:[email protected]>; [email protected] >> > <mailto:[email protected]> >> > >> > *CC:*draft-ietf-spring-srv6-network-programming >> > <mailto:[email protected]> >> > >> > *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 protected]> >> > *Date: *Tuesday, 15 October 2019 at 09:32 >> > *To: *Ron Bonica <[email protected]>, >> > "[email protected]" <[email protected]> >> > *Cc: *draft-ietf-spring-srv6-network-programming >> > <[email protected]> >> > *Subject: *Re: [spring] draft-ietf-spring-srv6-network-programming: >> > Section 4.16 >> > *Resent from: *<[email protected]> >> > *Resent to: *<[email protected]>, <[email protected]>, >> <[email protected]>, >> > <[email protected]>, <[email protected]>, >> > <[email protected]> >> > *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 protected] >> > >> > *From:*Ron Bonica <mailto:[email protected]> >> > >> > *Date:* 2019-10-15 02:42 >> > >> > *To:*SPRING WG List <mailto:[email protected]> >> > >> > *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 >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/spring >> > >> > > _______________________________________________ > spring mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
