Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 17 October 2019 16:14 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1035F1209CC; Thu, 17 Oct 2019 09:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwLaOpFnZrDn; Thu, 17 Oct 2019 09:14:16 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417AE120118; Thu, 17 Oct 2019 09:14:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 46vDkc0s72zVl3G; Thu, 17 Oct 2019 09:14:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1571328856; bh=HZonYkYigMdF2gPIO7xlnc3pTzMMeYtcEff8/GaXh2g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hUyGAaQDeqppS0LFEOVnx1v9llKZ1qg/NpXWDjZXsFAju8Wb2QroE4K/GsnCjYfOX Dfxv9iGJXWnTMJ+Z114PBeWD1LMlW2sU86ShP+D8YGFRk2Z7OIcWZc44fs5q+g0iPL /qQzjrzssLj9XUvsBKPNl2H/2BHTWgvzQQyp2l/c=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 46vDkb0z8FzVl2t; Thu, 17 Oct 2019 09:14:14 -0700 (PDT)
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>
References: <1CFF7617-C996-45C0-8338-D7BD0E4BC206@cisco.com> <4d6b2a58-957d-2c74-b6c1-6bd3cc03bf5e@joelhalpern.com> <E5E280C6-EE9E-4081-ADE5-0523DD312D04@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <4604bdbc-d5e0-3c7d-96b4-a91dfd90a1ef@joelhalpern.com>
Date: Thu, 17 Oct 2019 12:14:13 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <E5E280C6-EE9E-4081-ADE5-0523DD312D04@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/tDg0-cXmlb-a0e4kiyFp2yhQrdo>
Subject: Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 16:14:19 -0000
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 > > > >
- [spring] draft-ietf-spring-srv6-network-programmi… Ron Bonica
- Re: [spring] draft-ietf-spring-srv6-network-progr… li zhenqiang
- Re: [spring] draft-ietf-spring-srv6-network-progr… Wang, Weibin (NSB - CN/Shanghai)
- Re: [spring] draft-ietf-spring-srv6-network-progr… Ron Bonica
- Re: [spring] draft-ietf-spring-srv6-network-progr… Pablo Camarillo (pcamaril)
- Re: [spring] draft-ietf-spring-srv6-network-progr… Pablo Camarillo (pcamaril)
- Re: [spring] draft-ietf-spring-srv6-network-progr… Ron Bonica
- Re: [spring] draft-ietf-spring-srv6-network-progr… li zhenqiang
- Re: [spring] draft-ietf-spring-srv6-network-progr… Pablo Camarillo (pcamaril)
- Re: [spring] draft-ietf-spring-srv6-network-progr… Pablo Camarillo (pcamaril)
- Re: [spring] draft-ietf-spring-srv6-network-progr… Joel M. Halpern
- Re: [spring] draft-ietf-spring-srv6-network-progr… Pablo Camarillo (pcamaril)
- Re: [spring] draft-ietf-spring-srv6-network-progr… Joel M. Halpern
- Re: [spring] draft-ietf-spring-srv6-network-progr… Ron Bonica
- Re: [spring] draft-ietf-spring-srv6-network-progr… li zhenqiang
- Re: [spring] draft-ietf-spring-srv6-network-progr… Chengli (Cheng Li)
- Re: [spring] draft-ietf-spring-srv6-network-progr… Satoru Matsushima