Re: [spring] WGLC for

Stewart Bryant <> Thu, 22 July 2021 14:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D54813A47B5; Thu, 22 Jul 2021 07:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kYCU40UZNu2D; Thu, 22 Jul 2021 07:05:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C9CA3A47B6; Thu, 22 Jul 2021 07:05:50 -0700 (PDT)
Received: by with SMTP id n4so3417011wms.1; Thu, 22 Jul 2021 07:05:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=//8Dt4a04PQtBMPuoadih/jz7pR01YMe0LizOyPIEo4=; b=Lm/cjSpvu1hiP+Lhh5UlyA8uaWXJdeE5hqcQ6FN1HKLfsbmNntpS1OB98TnJpLVdiZ p0YY7eVFsc39yos3tvGlGDWA7LgPnN4BZJ18E1j6VI3m0pjmC6kjN4DxqX9/g2GoO1z+ mWHVTxYTXYF4aRiiw5v+afeW4+hJ8aR0Jw9PpU295uv+hH+a1S7EDKfbvBjAVF+4CTqf ZFoCDpOIzPgOtQvjwEN1fPr27U0vjLXMkdgIpEeRXLSbzPug0QNSqz/EpjWi+Pu86XSR 3qSTU+QI0oFvcmn4wfIDBCdOFSlmw2YoLm4Jao9I9faWNwMAlfxmdMTFHlxPU3Tzzo6n qBbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=//8Dt4a04PQtBMPuoadih/jz7pR01YMe0LizOyPIEo4=; b=FcYB2QhNeXSugRJIy9yE3KBJDTM7Jj53ZvGz5Lo9mO4F0XJnA2HqAEMnqlF2Jd5cSA IwDjVtp4mgbapDzQJA+QhWNbGbN1tZnNZQzH4Es4qhCZ5ArSqhfMkvd8SvCOvLCU671o N38uX0PTJYjtlKiAEthHFJE8R7aqBrKnTTCEWjnq3ZfbBrxpP2qHx/RQHdHcZMHtZQ6P nEMpssJPLjsQXBry+8b1fZobeTAJd+YFPYKTZPhYM6WmNQ76cPOV44TAzA/KsWvYUotn 7w2VQuc22qYwZjuKNKy/WQbxd03iiuxxb6Qcpna8GBk97+oXqWYCS5p/JgqZbKcU+OXr wG3A==
X-Gm-Message-State: AOAM530YGnfYBVqehwrux8Ncrb6Y9nXqcGLrbVg3WRBSJmLQ3bdmpM62 JJWN7Dbvk3X6+s12GXGL29w=
X-Google-Smtp-Source: ABdhPJwIPHUsY1bcn4NG9ojEOO4zjrgRlK4t/Z733IJ29kNcJNh4zdwYCjzl6u9Yka8JwWIef09suw==
X-Received: by 2002:a7b:c150:: with SMTP id z16mr9357734wmi.104.1626962743338; Thu, 22 Jul 2021 07:05:43 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id y12sm12783114wmc.12.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jul 2021 07:05:42 -0700 (PDT)
From: Stewart Bryant <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DCFB3399-BE14-47F5-9940-07A37FC9AF45"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Thu, 22 Jul 2021 15:05:41 +0100
In-Reply-To: <>
Cc: Stewart Bryant <>, "" <>, "" <>
To: James Guichard <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [spring] WGLC for
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jul 2021 14:05:57 -0000

Once you find yourself needing to include path identifiers in an SR packet, I begin to wonder whether the segment routing design has gone off track.

In MPLS we have the ability in both PCE and RSVP to lay out end to end paths in such a way that the forwarding label is the path identifier. If you recall the MPLS-TP approach you could deduce everything about the packet’s origin and path from the arrival label which was not PHPed.

Assuming there are technical reasons why such a classic approach is not possible, I wonder why it is necessary to encode the path identifier within label stack itself with all of the constraints that imposes on the size and semantics of the identifier.

An alternative approach is to look at the meta/ancillary data work that is going on in MPLS and carry the path identifier below the bottom of stack.

At  its most basic level this analogous to the approach to constructing a Pseudowires, with an outgoing label stack, a control word (which can be an extended control word carrying the path information) and then the payload.

Such an approach would allow the packet designer to carry either the identity of the path, or the actual set of labels use to construct the path, or the reverse path or some combination of these. The latter two approaches are more dynamic than the approach proposed in this draft and more in keeping with the fundamental design philosophy of SR.

- Stewart

> On 22 Jul 2021, at 14:02, James Guichard <> wrote:
> Dear WG:
> The WGLC for this document will be extended for a further 2 weeks ending August 4th 2021 so that feedback can be obtained from the WG. Other than the authors there has been little input so please respond on the mailing list with any comments etc. 
> Thanks!
> Jim, Joel & Bruno
> From: James Guichard <> 
> Sent: Wednesday, July 7, 2021 11:49 AM
> To:
> Cc:
> Subject: WGLC for
> Dear WG:
> This email starts a 2 week Working Group Last Call for draft-ietf-spring-mpls-path-segment [1].
> Please read this document if you haven’t read the most recent version and send your comments to the SPRING WG list no later than July 21st 2021.
> If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.
> Lastly, if you are an author or contributor please response to indicate whether you know of any undisclosed IPR related to this document.
> Thanks!
> Jim, Joel & Bruno
> [1] <>
> _______________________________________________
> spring mailing list