Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt
Robert Raszuk <robert@raszuk.net> Fri, 28 February 2020 16:46 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 356043A1B45 for <spring@ietfa.amsl.com>; Fri, 28 Feb 2020 08:46:18 -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=unavailable 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 PKPcLsU8Z2Bj for <spring@ietfa.amsl.com>; Fri, 28 Feb 2020 08:46:11 -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 B99703A1B3E for <spring@ietf.org>; Fri, 28 Feb 2020 08:46:11 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id j80so1440452oih.7 for <spring@ietf.org>; Fri, 28 Feb 2020 08:46:11 -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=KPwyPW3BKLVYsxajf7AIjlnxyIBj46eytRYZNBifoL4=; b=eLtUzwW9UIkm8++K1KmqQ1ck1DxBnZ1MQ2F6TuQOlse5h4ZU1nBZsQ8icWtB6RwkJZ CBCZDRFwNwD64MStFRWK1hXSkcNEWHk1Mq02coC4CYvnlf8A6XWoRYiiLVLptNIcJOr2 9jAAhtDW+QWMQBYNNwKuF1k1bpmaAQqkgpd2qA8vsRoCYvC+HfHnIwmDNiWE9ab2MDlZ NsNa8jndNTvFRD4xHlgXUmgRLIsnoVYKWPTIu0gy3TJq8tnoBvKkz5FyMjoscnA89bKg hzS3v4+cfVwUA8sE7Op4hNBQ7m/eJMqVmmcNWffxsVVqOwpzdp8zNbaxMJxAgdFU/XJg TdVA==
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=KPwyPW3BKLVYsxajf7AIjlnxyIBj46eytRYZNBifoL4=; b=WiOwwesZSIbz/dbn4LMbU5+FeG3GjUI2Uf2gZxVgytwaECGr6DBubg74dM8ZOWPIbV t+74+zb7Y2k4U8Ji302PFVzxcuJ0UbIvSppQDKbiIGblZpSRiJUhIwP3IYrr35O5tw/9 52FoG9ymJoU+jqPOiMIRSDxvQ+cQsvJoyDy/wMcK1HoHzKU7t31WEdVzxz4DsOwZcZ/U b/83zH1kYaKoYz0XJlklM7R7CebEGD44PoJQ1J0IgHkGjoMc4iPvPyJdLQxrjka5CGGg S31FUrw6269ncv8xaIxFn6f8/9/wQkEfztrsSk1rDyjtiHV9x3x8haFzH12mbxjSyGBG QHNQ==
X-Gm-Message-State: APjAAAXwBhpViXqYKEC/cNKAHWxCoCR3dFJsn6fNeHW+ShG/mfgQA2RM RcN8Bz6JJIjl1b0XCPDyOGmsnz+7Mdm3MvKdfTyApw==
X-Google-Smtp-Source: APXvYqxVmO2+FlzhHppljs4kr6iMXS0gJVlWajzogrSn7snroG8nJ7BOKgYiNPdGz9gl3VsVGIk/VHUWVtzTnQFzmdw=
X-Received: by 2002:aca:4306:: with SMTP id q6mr3867992oia.54.1582908371006; Fri, 28 Feb 2020 08:46:11 -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> <CAOj+MMH8nWk2+py=kh09-B9DKhoLp8e7WDNX=vwBjeatABpk7g@mail.gmail.com> <CA+RyBmUAmhhVWhKD6zgpeGdqbakL-d1-gAhKksGbmJTsZ_Dd2w@mail.gmail.com>
In-Reply-To: <CA+RyBmUAmhhVWhKD6zgpeGdqbakL-d1-gAhKksGbmJTsZ_Dd2w@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 28 Feb 2020 17:45:56 +0100
Message-ID: <CAOj+MMHYfHwa=mZ+XWGuoNjmOqqdXRH61fBMVDtwiScykWnJvQ@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="0000000000002a8b87059fa5938c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/moZaYYE4UkqgMyGK4qePHdKtWsU>
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:46:18 -0000
Even better ! Thank you, R. On Fri, Feb 28, 2020 at 5:44 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Robert, > thank you for you consideration. Pablo and I had discussed references to > OAM in the SRv6 network programming draft. Pablo and authors kindly agreed > to remove all references to OAM and draft-ietf-6man-spring-srv6-oam. As we > are discussing the network programming > draft, draft-ietf-6man-spring-srv6-oam is in WGLC at 6man. My intention was > to work with the authors of SRv6 OAM draft on documenting its relationship > with PSP. Would that make sense? > > Regards, > Greg > > > > On Fri, Feb 28, 2020 at 8:37 AM Robert Raszuk <robert@raszuk.net> wrote: > >> 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)