Per segment service instructions

Robert Raszuk <robert@raszuk.net> Fri, 13 September 2019 12:45 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137EF120801 for <ipv6@ietfa.amsl.com>; Fri, 13 Sep 2019 05:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 n0jKweWjvkQM for <ipv6@ietfa.amsl.com>; Fri, 13 Sep 2019 05:45:09 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 146981200F3 for <6man@ietf.org>; Fri, 13 Sep 2019 05:45:09 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id u40so33674622qth.11 for <6man@ietf.org>; Fri, 13 Sep 2019 05:45:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=qb32YtDBunLeH/SMc2l4Uix35exPIFe9OXVi8Q3EH5w=; b=WTZtkrL3x45zkAMI/Td7PNMHi7caWuqU6HVv8W4HKmLhyMSYWtfhAyFt+BLlCdwXlS n8SP42gI5BLx77wb4Jef7p9UIIOeMiNaffKnxhi9nmdnkl5t0wiKVwfXhxa4VLXsWvJZ PIjYX+ie0ekFroX3SiHoHvNf5m2k9P4Zw4mQgg5fHly8lg6HgxRnIyeUlq0kBYWFN73U +zfkOGKX7VJbOqMJU+d9esssooCLwO9XJ6CMoxCmUjFfud1VAg09k/T/SFZ/to5IsPF2 JDEMHIhzduaD2kvmSr/+wqvpYDSDvi1Iz2pKnSavFzFucFB5E44SQ0EcOgEDw2EFD13k RY7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qb32YtDBunLeH/SMc2l4Uix35exPIFe9OXVi8Q3EH5w=; b=fQh/sFEA07Gia1mAfaUDF+hiLj4npGWyepHzd/N0fFmrj+yfJ9PERJ/fTFp1Fdv6X3 YlLh2qNDFPCXqhpCDdAFW9qLtkF9FYzgclNH9ZJfkWLikr2YGH4gKs2JD6gUjuXATSLN 6HdMwwjWr9niJb7Zd9T2WtvyzHrQWLPJyI5B1JfUtiwJdqiBjF74xkwtp1j6CDUv3KNm 1R94Rr7dATr1jVc1zjzbAelASEHGM+mFXjb4+JTT0ftt/FYwwDxKSb64nDbeVCjMdDv/ TV0UmRnPqyAU4lkcAvPCJo8webCVboJ74i/FeRZg5wr4isoAOw26z5tDSKqS4a5CTkWh Jy3g==
X-Gm-Message-State: APjAAAXh5/9ivbmMJV0yNzzNeAM6qKF5faECOs5WCK52j37cKKrviQjm kti5pUs8lhFNdjcOVMb+uS50/U9TZFtrnnRCXCNuvg==
X-Google-Smtp-Source: APXvYqyiI5djQ1H/fWJqkjeqzSDAD6sGzOSiZiJfT7jSxuZ2a9RDS4lhw3n4tAbYQ8lBbgSLli/Nmfs6FMzV4iRgIgw=
X-Received: by 2002:ac8:4612:: with SMTP id p18mr2675346qtn.94.1568378707951; Fri, 13 Sep 2019 05:45:07 -0700 (PDT)
MIME-Version: 1.0
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 13 Sep 2019 14:44:52 +0200
Message-ID: <CAOj+MMG7ZavvdDN3meoxe3TbJa2BoRnQknmfoYH=416KsT-3WA@mail.gmail.com>
Subject: Per segment service instructions
To: Ron Bonica <rbonica@juniper.net>
Cc: SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c2d41d05926e9f39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1oFE9SFMG8crwOIl-3ObVOl-YtM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 12:45:11 -0000

Dear Ron,

I have read yet one more draft from the SRv6+ package defining another
Destination Option type - this time Per Segment Service Instruction(s)
described in draft-bonica-6man-seg-end-opt

I have one technical question regarding it.

Imagine I have following topology - drawing only what is relevant to the
question:

PE1 - - P1 - - SE1 - - P2 - -  SE2 - - P3 - - PE2

When packet enters the network PE1 is instructed to program my flow A to
execute following following functions on Segment End 1 (SE1) and Segment
End 2 (SE2):

SE1 - When packet is routed out of SE1 consider only interfaces of bw 10G
and up

SE2 - When packet is routed out of SE2 make sure that path to segment end
node is no more then 2 hops away.

>From reading the draft I think the answer is that you mandated the segment
end functions in SRv6+ to have domain-wide significance such that the
function itself contains not only the instruction but also as it is of
domain-wide significance the location of the instruction to execute it on.

So far so good ... Flow-A get's CRH and PSSI encoding the above
requirement.

When packet enters SE1 Destination Options preceding RH is read and PSSIs
are attempted to get executed ! Both instructions are tried but only one is
known so only one get's executed on SE1. Same story on SE2.

Not sure if eveyone would be ok with such model to read and attempt to
execute instructions which are not for a given end segment but let's assume
some may accept it.

But now how unfortunate it may sound PE1 is receving the flow-B and for
flow B the requirements are opposite:

SE1 - When packet is routed out of SE1 make sure that path to segment end
node is no more then 2 hops away.

SE2 - When packet is routed out of SE2 consider only interfaces of bw 10G
and up.

Well what do you - simple - you allocate another two domain wide functions
and encode it in the packet at PSSI DOH on PE1.

But if my description matches the plan you now end up with per flow !!!
state in the network which is the price to pay for splitting SIDs with its
functions into completely different headers.

I don't know about others but I think we went in the past via multiple
attempts to put any per flow state into the large network and it all failed
when faced scale.

Also SR specifically in its architecture RFC8402 says that segment routing
is "maintaining per-flow state only at the ingress node(s) to the SR
domain."

Kind regards,
Robert.