Re: [spring] Is srv6 PSP a good idea

Mark Smith <markzzzsmith@gmail.com> Sat, 14 December 2019 23:03 UTC

Return-Path: <markzzzsmith@gmail.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 53FFD120088 for <spring@ietfa.amsl.com>; Sat, 14 Dec 2019 15:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mKrVTGr9nHh2 for <spring@ietfa.amsl.com>; Sat, 14 Dec 2019 15:03:34 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D82120044 for <spring@ietf.org>; Sat, 14 Dec 2019 15:03:34 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id v140so2658640oie.0 for <spring@ietf.org>; Sat, 14 Dec 2019 15:03:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=farbH1LguWU6amiKGh82LuCTC/bqHJF0opEBlmXx9Jc=; b=Yo81r93nuobky+eTCAULF9H99V/bGZ3osQQ+Mu+ak6GkdoI6u+ikvqX0e8dSNoFJUi iRoycGkYkSV6w2XqHOYdKVOnQje/PWi5NtL6CYuTcT6VW7LmQuc6yhfZ/H93j6fNFXVI vLnpDLOGImHQT1idJakwiw3pv4Mf2mmAwr7Rp4p0emXIvej0Em8rvfHHCTjVg0kp0GdA E7vuX4n6UYtfLka/lZFuxC4RJEgGfqKRiRoWpmFmqLesoWEB7JKOarLwwXtM+HPO2SxB PcNwz9jZ+u9O+1FN5kVZrKxHnhLUuOrn0CT/690d3IIVP9plPAlaknpY0WVNIpk/wOq6 2DKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=farbH1LguWU6amiKGh82LuCTC/bqHJF0opEBlmXx9Jc=; b=SsWPzgvX2bcYplUkShpgMYY4+zpysbxyKxFDmS/TBWyZ+5qJhOs7vchKozhJ/d2rA2 AaeXVJ+9hcZYMrCbEAVcbKKU0uAKqFtUYi/juGLVoq1thjKqN3kOEarpHAtEoC00e5Eb +CzGjLmRBkSy6N5kn7401kX0ptrdBzd80VBBFqwQWtCQQFP1TUDjMIMSTBLrFGbJ8W/2 4Wr0hexjqp2cyr3cKI/C/9ZkODxWHke7LYBdPzpA9mcElXARkgS0kHaUG7+2rhGb6DgL 98i3dboDYoWqVMGrTj/xyCeBc5rP52d/IR3V41Ufh3f2qE+S3mvdEOzAn5ZBEZtZ07eh tnLw==
X-Gm-Message-State: APjAAAV0mbgXCCgIHR531ZYqKCeIpxFI4Z6l9zwsVAo3DrhzTjCttIbC lOw80IORZsWPFf7ujL1HiE3cp9KMCQsulHBL+nY=
X-Google-Smtp-Source: APXvYqxCBts+Jc1mFvN06nVg5ivEMmEt7URp7zMlLWzNpdujqBmOidRazWW8ekgFK4rcqt2g5dpL/BpgJxLuxoeGKWk=
X-Received: by 2002:aca:cf50:: with SMTP id f77mr8995421oig.60.1576364613327; Sat, 14 Dec 2019 15:03:33 -0800 (PST)
MIME-Version: 1.0
References: <5c2a4b36-0c59-709e-23eb-00f4aa1ce52f@joelhalpern.com> <16253F7987E4F346823E305D08F9115AABAEB42B@nkgeml514-mbx.china.huawei.com> <d24357eb-c137-d14e-e394-0e49d7eff7bc@joelhalpern.com> <16253F7987E4F346823E305D08F9115AABAEF03A@nkgeml514-mbx.china.huawei.com>
In-Reply-To: <16253F7987E4F346823E305D08F9115AABAEF03A@nkgeml514-mbx.china.huawei.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 15 Dec 2019 10:03:22 +1100
Message-ID: <CAO42Z2yb83737v0HFPJmOgXJzq0kGSHFguEyk2YLGAUMS_q0MQ@mail.gmail.com>
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d061bd0599b1fc20"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/2t7TFc4qn4Q4wII-f1yZKQAqxjY>
Subject: Re: [spring] Is srv6 PSP a good idea
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: Sat, 14 Dec 2019 23:03:36 -0000

On Sun, 15 Dec 2019, 03:07 Xiejingrong (Jingrong), <xiejingrong@huawei.com>
wrote:

> Hi Joel,
>
> Regrading this question:
> Do you have any comments on what appears to be the significant increase
> in complexity on the device performing PSP?
>
> I think the removal of some bytes from an packet header is a common case
> without any significant increasing complexity for a long time.
> For example, a Layer-2 switch receives an ethernet frame from a port with
> a vlan tag, and forwards/switches it to another port without a vlan tag,
> then it strips the 2 bytes of vlan tag value and 2 bytes of 0x8100. The 4
> bytes are in the middle of the ethernet header and the ip header, which
> otherwise would not need to be stripped if it's the case from a tag port to
> another tag port.
>


According to Radia Perlman, in her book, "Interconnections", 2nd edition,
this was a work around to some NICs at the time not supporting sending and
receiving frames large enough to do full Ethernet-in-Ethernet tunnelling to
add VLAN information.

Cisco had implemented a pre-standard version of VLAN tagging - Inter-Switch
Link (ISL), which is what had inspired the IEEE to standardise VLAN
tagging. This used E-in-E tunnelling. This was possible because Cisco knew
what its hardware was capable of.

https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html


The checksum (FCS) of a frame is calculated at the sender (identified by
SA), so that the intended receiver (identified by the DA) can determine if
the frame was corrupted in flight.

VLAN tag insertion violates this end-to-end function of the checksum,
because the checksum is recalculated when VLAN tags are added.

When the frame arrives at the DA, the checksum isn't validating the frame
that was sent by the SA, it is only validating the frame that was sent by
the last device to remove the VLAN tag that then recalculated and updated
the checksum.

Those who designed IEEE tagging didn't do insertion because they wanted to
or thought it was a good idea. They didn't have a choice if they wanted to
be available with existing Ethernet chipsets.


> I found this in my book, "Network system design using network processors"
> by Douglas E. Comer 2004.
> On page 38 "4.12 Operation and Data Chaining", introduced modern NICs use
> a technique known as “operation chaining or command chaining” instead of
> operating on a single large buffer.
> Which makes me believe that, the removal of some bytes from some packet
> header (L2 or L3 header), would not cause the 1500 bytes of packet be
> moved, but instead a very basic function that various packet processors
> have solved very long ago as a basic function of "header/packet
> modification".
>
> Hope the above understanding is right.
>
> Thanks
> Jingrong
>
> ________________________________________
> From: spring [spring-bounces@ietf.org] on behalf of Joel M. Halpern [
> jmh@joelhalpern.com]
> Sent: Wednesday, December 11, 2019 22:15
> To: spring@ietf.org
> Subject: Re: [spring] Is srv6 PSP a good idea
>
> Thank you Jingrong for providing some of the other motivations.  Two
> furhter comments.
>
> As far as I know, the only savings on the end box is the processing for
> noticing the SRH, noticing that SL is 0 and there are no relevant TLVs,
> and then moving on.
>
> If the actual end device is not part of the SR domain, I assume that
> encapsulation would have been used, so I think it is reasoanble to
> assume that in the PSP case the end device is SR capable.
>
> Do you have any comments on what appears to be the significant increase
> in complexity on the device performing PSP?  The question I am trying to
> get at is about the tradeoff, which needs one to evaluate both sides.
>
> Yours,
> Joel
>
> On 12/10/2019 11:13 PM, Xiejingrong (Jingrong) wrote:
> > I think it's a good idea.
> > Nothing new, but benefits that people have already said seems notable to
> me.
> >
> > (1) reduce the load of final destination. This benefit can be notable
> for the following sub reasons.
> > (1.1) final destination tends to have heavy load. It need to handle all
> the EHs and do the delivery/demultiplex the packet to the right overlay
> service.
> > (1.2) example 1, the final destination may need to handle the DOH after
> the RH.
> > (1.3) example 2, the final destination may need to do the assembly of
> fragmented packets.
> > (1.4) example 3, the final destination may need to do AH/ESP after the
> Fragmentation Header.
> > (1.5) example 4, the final destination may need to deliver the packet to
> the right overlay service.
> >
> > (2) support the incremental deployment when final destination(s) do not
> process/recognize SRH. This benefit can be notable for the following sub
> reasons.
> > (2.1) A core router may (fan-out) connected with a big number of low-end
> routers that do not support SRH but support tunnel-end/service-demultiplex
> function of SRv6.
> >
> > Thanks
> > Jingrong
> >
> > -----Original Message-----
> > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Joel M.
> Halpern
> > Sent: Wednesday, December 11, 2019 10:55 AM
> > To: spring@ietf.org
> > Subject: [spring] Is srv6 PSP a good idea
> >
> > For purposes of this thread, even if you think PSP violates RFC 8200,
> let us assume that it is legal.
> >
> > As I understand it, the PSP situation is:
> > o the packet arrives at the place (let's not argue about whether SIDs
> are locators) identified by the SID in the destination address field o that
> SID is the next to last SID in the SID list o that sid is marked as / known
> to be PSP o at the intended place in the processing pseudocode, the last
> (first) entry in the SRH is copied into the destination IPv6 address field
> of the packet
> > -> The SRH being used is then removed from the packet.
> >
> > In order to evaluate whether this is a good idea, we have to have some
> idea of the benefit.  It may be that I am missing some of the benefit, and
> I would appreciate clarification.
> > As far as I can tell, the benefit of this removal is that in exchange
> for this node doing the work of removing the SRH, the final node in the SRH
> does not have to process the SRH at all, as it has been removed.
> >
> > I have trouble seeing how that work tradeoff can be beneficial.
> > Removing bytes from the middle of a packet is a complex operation.
> > Doing so in Silicon (we expect this to be done in the fast path of
> significant forwarders as I understand it) requires very special
> provision.  Even in software, removing bytes from the middle of a packet
> requires somewhere between some and a lot of extra work.  It is distinctly
> NOT free.
> >
> > In contrast, we have assumed that the work of processing SRH itself is
> tractable, since otherwise all of SRv6 would be problematic.  So why is
> this necessary.
> >
> > Yours,
> > Joel
> >
> > PS: Note that both the MPLS case and the encapsulation case are very
> different in that the material being removed is at the front of the IP
> packet.  Pop or prepend are MUCH easier than middle-removal (or
> middle-insertion).
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>