Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-10.txt

Greg Mirsky <gregimirsky@gmail.com> Fri, 28 February 2020 16:22 UTC

Return-Path: <gregimirsky@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 8AE4D3A1B9D; Fri, 28 Feb 2020 08:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=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 ps5JGBqukYyW; Fri, 28 Feb 2020 08:22:40 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 70E593A1B92; Fri, 28 Feb 2020 08:22:39 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id n25so2552547lfl.0; Fri, 28 Feb 2020 08:22:39 -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=ColBaUEXnbvWnV9YNJ3JVt6ssGHabyRkx/ccV7qAi8o=; b=GUmkMyx/Qb72x0fD+bnA6vfVLEs8e4tywfzP44izlJECQLIZ7qB8SDaCYcB9TZ1V9n XXhhZZQ1XoeG2lBmo7S1fEjmqr8Fd52t17tRpUgaeiMWzGIcyRI8MOJ1k49C/ZISf7w8 y/piIKoEJnydTipWXvrUHg5L8fLqudQzEAeslnPKAkBcxX5RPv7dOmDLfkh5u6GIK1Hm mc+FCceRqnPFCxvPFzm84k6GlQ1WeuxJOBCeifCAW7eiEsp/O1YOrt6/SiFHayNtR3z0 SLEJMg5m1eJiy0v/6JtjJFoPn5VyIgcYUTtWSV2NWF5dMRzHBInmQblRafo64EuZLT72 WEpw==
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=ColBaUEXnbvWnV9YNJ3JVt6ssGHabyRkx/ccV7qAi8o=; b=qzOqDWdqtBPs9G7DqSX6qEAzyUdoJzMgjDSoiBe4o/VjCjlwFEBIH4BE4uoh6nixGG 23gVDQo1kp0+7hjPhI9NW5TRkBsS/o0efDjS9TsYtwKRzouDXBrM6Hi2NCeN/Kt9U3gC xP7IWi6RS2BCnwHSApzQPQ+1ff95NscW4qvdGJjTs7aiz0wWI7SOXkhfDgeY/R8pzSkk 1qj9zlaYtPjDO28U1Cz9lTzWyiRjOurNLsgurWf9WJFSUOGZIFr0rI2OsgH5Ar+gEUYp bEWcCRL5WfTE8+k1qyBFyDt4T3cyE36/sNq1eiRyz1eVc3QJSSWrCsPbL0R4KlltmX0w dh1A==
X-Gm-Message-State: ANhLgQ3Vy73izRoA78H2VeMAfqNCAr1oCtkvlUYFoexXOCq3H5GdaSM3 +K8Zv1jvK7dBpIJUgR1DN2asP4aLeSkyw2tqlwI=
X-Google-Smtp-Source: ADFU+vvFeo2w8jPB03MwR91Ki2zif4rTWb1Hm2pSRi3tY54KDxp+Eb9HPnaG6pFbp0ed2OQbZTJbDkdJHu5GEHLfBzg=
X-Received: by 2002:a05:6512:3191:: with SMTP id i17mr1497442lfe.33.1582906957452; Fri, 28 Feb 2020 08:22:37 -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>
In-Reply-To: <CAOj+MMEY+gEPZ3RVp7tcL5q-D-N-hwjmXYY_cFi_OuNQ7+SrbA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 28 Feb 2020 08:22:25 -0800
Message-ID: <CA+RyBmVH3D1Xpa=PArVipmcSYL60Q9bFuKS409JF2JwZf7a6fQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e95b79059fa53eae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/03tDq3dgmQl56xe1wfz0YOLvYng>
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:22:46 -0000

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
> --------------------------------------------------------------------
>