Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt
Robert Raszuk <robert@raszuk.net> Fri, 28 February 2020 16:37 UTC
Return-Path: <robert@raszuk.net>
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 7F86E3A1B1B for <spring@ietfa.amsl.com>; Fri, 28 Feb 2020 08:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 WYKqqN1QyZCK for <spring@ietfa.amsl.com>; Fri, 28 Feb 2020 08:37:17 -0800 (PST)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 506B83A1B13 for <spring@ietf.org>; Fri, 28 Feb 2020 08:37:16 -0800 (PST)
Received: by mail-oi1-x231.google.com with SMTP id d62so3383009oia.11 for <spring@ietf.org>; Fri, 28 Feb 2020 08:37:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZAp0DeYhorsTHRZuOhStjoyx+R0f7p2HB/SsQvhsh78=; b=RxslCeXU0yqFjbwosbf8Dk9LcYEGHM85s/z9sx/eb3crCmM7KKJiXgQXLKpuIDuNdw OPbX5yT/K9o4lkHon4+hpkpG67UMv6vCDGngJSJXJ6/EnBmOudVGsFi9uht/zNoH75B1 9liC7Rj4IY5/0SgFDrEcrzrlbhzk2DuFyZC/dmh/T6Mt08dUqcBU151YmDjuW5UAzYJm 72LcO0cYiuxIYFG1Smmsp0DFDcMOTix8lyCNZRjia7+jfS9zWO3ad7lajD0IOoua1QUg w81ojNOh1gjesgOeYSod1xmSgnYVDxwizdyY8FY/7Ua5bAzSxPjxOI2zQddyfSEC29Je d1eA==
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=ZAp0DeYhorsTHRZuOhStjoyx+R0f7p2HB/SsQvhsh78=; b=O3EISF6zqc3OmCxNMN5tVo8aA6CF85VLpoe+i1oz0R+jp/3Db/ZdUCGhDNQ2GmJKII cWwnsdzHRuMPFXkrOtI1uYp4Yl3vBc75+p9j2rM4c/Yg960rtKt8xuZfWav61MZHiemV erSrIhL4ttItQUcenKKekUd3NWkgDxZrJxCW2hRdRgaH3OowOr4+rOeRcT5CLPzCwBtA Bq+XOx4MZb5w3Am4ZOafLTzggbP8s8J40X3eedQ6/qWrurnQFVNV028jrvV/Dd887lTb M1R8i4C7OlaP72gZx2ra2RzK1qDPtIdZ22STktPW5E0JpgaOYGk/GXZQ6zGNQUlOoiCf q26w==
X-Gm-Message-State: APjAAAUcx+kCItZA9DTS4RWDRtTFpVNhNx/3LJg+E0uVIN/4xka6k/SL QaJRc1m8FRJaMauqEFU/8k8Wtf9ARMENjY7uAc7WEw==
X-Google-Smtp-Source: APXvYqwu932vB3QHKNkoSTfoD07/0rOeRjDFQD/Ko11FD1/I+RYD5Y1EatZu4UnNO6SQEJ3y2CjH0ncsXQhBZxDG1w8=
X-Received: by 2002:a05:6808:611:: with SMTP id y17mr3686457oih.146.1582907835927; Fri, 28 Feb 2020 08:37:15 -0800 (PST)
MIME-Version: 1.0
References: <158248836511.1031.1350509839394231473@ietfa.amsl.com> <7481061F-75A5-4E4D-80AE-40E1F933E94A@cisco.com> <1BB7ED35-98EC-4A73-92A3-AD043D462CF7@steffann.nl> <CAO42Z2zOr_8Ptukf_WE8hWOUUH1vXFig-=fNWhNeweruibQDhw@mail.gmail.com> <DBBPR03MB541525FF72B82416A020B632EEEC0@DBBPR03MB5415.eurprd03.prod.outlook.com> <DM6PR05MB63489BE3D1C669C277D64906AEEC0@DM6PR05MB6348.namprd05.prod.outlook.com> <BEE51E09-0929-4F48-B5B3-6BAB23E07DAB@cisco.com> <CABNhwV3q4MAopb0oXSw4uHezfVLjMnvf8h4BzFY_q8LS7dCXVw@mail.gmail.com> <97141983-EDF7-4C1E-A8F1-4ADCD345BC5A@cisco.com> <DM6PR05MB634859429BEBC90FFA687936AEEB0@DM6PR05MB6348.namprd05.prod.outlook.com> <470E6DF4-0EF8-4EC8-8F84-1D5C84CEC5B9@juniper.net> <CAOj+MMEY+gEPZ3RVp7tcL5q-D-N-hwjmXYY_cFi_OuNQ7+SrbA@mail.gmail.com> <CA+RyBmVH3D1Xpa=PArVipmcSYL60Q9bFuKS409JF2JwZf7a6fQ@mail.gmail.com>
In-Reply-To: <CA+RyBmVH3D1Xpa=PArVipmcSYL60Q9bFuKS409JF2JwZf7a6fQ@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 28 Feb 2020 17:37:01 +0100
Message-ID: <CAOj+MMH8nWk2+py=kh09-B9DKhoLp8e7WDNX=vwBjeatABpk7g@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000460b41059fa573ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/zUZLIKl9rvd1apnLEfme7iMGYgk>
Subject: Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt
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: Fri, 28 Feb 2020 16:37:20 -0000
Greg, I agree. Moreover I would suggest to add such text that PSP endpoint behaviours should or must not be set for any OEM packets. Would that help ? Thx, R. On Fri, Feb 28, 2020 at 5:22 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Robert, > you've asked about a possible operational drawback of PSP. I think that > for OAM PSP has decremental effect on the usefulness of performance > measurements as there's no obvious information to identify the path a > packet traversed. > > Regards, > Greg > > On Fri, Feb 28, 2020 at 2:55 AM Robert Raszuk <robert@raszuk.net> wrote: > >> Hi John, >> >> > I have an additional observation, or question, about Dan’s scenario. >> Almost all communication is bidirectional. >> > Presumably this means a router that’s the tail end of an SRv6 path in >> one direction is the head end in the other. >> >> While your observation is correct that most TCP connections are bidir SR >> in a lot of cases can operate only in one direction. Needless to say it can >> also be used with UDP streaming. >> >> To extend Ketan's OTT video example let me observe that in a lot of >> transactions queries from clients are tiny and do not TE capabilities while >> responses are huge and bursty and may indeed benefit from special handling. >> >> Sure if you think of applications like VPNs than you are right .. >> regardless of the size of the packets proper tagging must occur in either >> direction - but this is just one use of SRv6 perhaps not even the major >> one. >> >> - - - >> >> Now as one friend just asked me offline - putting all IPv6 dogmas aside - >> what is the technical issue with removing previously applied extension >> header from the packet within a given operator's network ? What breaks when >> you do that ? >> >> Thx, >> R. >> >> >> On Thu, Feb 27, 2020 at 10:11 PM John Scudder <jgs= >> 40juniper.net@dmarc.ietf.org> wrote: >> >>> I have an additional observation, or question, about Dan’s scenario.. >>> Almost all communication is bidirectional. Presumably this means a router >>> that’s the tail end of an SRv6 path in one direction is the head end in the >>> other. Doesn’t a head end need to add an SRH? If I’ve gotten that right, >>> then we can extend Ron’s list with one more item. That is, apparently the >>> ultimate segment endpoint: >>> >>> • Can process a SID, received as an IPv6 DA, on the fast path >>> • Cannot process an SRH on receipt, even if Segments Left equal 0, on >>> the fast path. >>> • Can add an SRH on transmission, on the fast path >>> >>> Even though strictly speaking the second and third bullet points aren’t >>> mutually exclusive, it’s a little difficult to imagine a real router that >>> would have both these properties simultaneously. Perhaps I’m not being >>> creative enough in imagining deployment scenarios? Since this scenario is >>> claimed as an important reason this problematic feature is needed, it would >>> be great if someone who understands it would elucidate, thanks. >>> >>> One further point, Ron says “I wonder whether it is a good idea to >>> stretch the IPv6 standard to accommodate IPv6-challenged devices.” I also >>> wonder this, especially because these devices will have a relatively >>> limited lifetime in the network.[*] I don’t find the cost/benefit >>> attractive of making a permanent detrimental change to the IPv6 >>> architecture to accommodate a temporary deployment issue. >>> >>> Regards, >>> >>> —John >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >
- [spring] I-D Action: draft-ietf-spring-srv6-netwo… internet-drafts
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Pablo Camarillo (pcamaril)
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Sander Steffann
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Mark Smith
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Andrew Alston
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Ron Bonica
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Pablo Camarillo (pcamaril)
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Gyan Mishra
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Mark Smith
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Pablo Camarillo (pcamaril)
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Voyer, Daniel
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Pablo Camarillo (pcamaril)
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Gyan Mishra
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Ron Bonica
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Robert Raszuk
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Andrew Alston
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Pablo Camarillo (pcamaril)
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… John Scudder
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Ketan Talaulikar (ketant)
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Gyan Mishra
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Robert Raszuk
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… John Scudder
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Joel M. Halpern
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Robert Raszuk
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Greg Mirsky
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Robert Raszuk
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Ron Bonica
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Greg Mirsky
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Robert Raszuk
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Greg Mirsky
- Re: [spring] I-D Action: draft-ietf-spring-srv6-n… Zafar Ali (zali)