[spring] Understanding the replication draft

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 29 June 2020 22:17 UTC

Return-Path: <jmh@joelhalpern.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 2AA703A0DB7 for <spring@ietfa.amsl.com>; Mon, 29 Jun 2020 15:17:40 -0700 (PDT)
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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 oJFZFpj_Q2wk for <spring@ietfa.amsl.com>; Mon, 29 Jun 2020 15:17:38 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6D43A0DB2 for <spring@ietf.org>; Mon, 29 Jun 2020 15:17:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49whgk3l25z6GJj3 for <spring@ietf.org>; Mon, 29 Jun 2020 15:17:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1593469058; bh=CdwBkuVKtfcjGmIYJi1ZwCBexG9mYffitvkIIDf9C5A=; h=To:From:Subject:Date:From; b=Juyn9TGm6Jhfu6wYyl5NbnuiwiEKnzvPtTQHWLsB9l8m/UMq4WJU4Md9whudnDGIa LKCa2Spnyes8Fk4vh/XYCDTEEAZb4O4Akb08wcdzHQAb/Y6+73J3vRv65XA9pouiBB 60SupFQVNMRaTCP06izvV+2PvezsWFhXL2fPoMM0=
X-Quarantine-ID: <hi9oAht6VIrs>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 49whgk0qFCz6GJkY for <spring@ietf.org>; Mon, 29 Jun 2020 15:17:38 -0700 (PDT)
To: "spring@ietf.org" <spring@ietf.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <94415742-fc4e-1774-bf96-01eac3672bfb@joelhalpern.com>
Date: Mon, 29 Jun 2020 18:17:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/px2C7_qO4szbm4Evli93lrymvFU>
Subject: [spring] Understanding the replication draft
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: Mon, 29 Jun 2020 22:17:40 -0000

I asked the authors a version of this question, but apparently my 
request got lost.

For now, this is speaking as an individual.  And I sincerely hope that I 
am merely missing something obvious.

I can not figure out from the current draft how the replication segment 
works in a SID (or label) stack.
Is there an unstated requirement that the segment must be the last one 
in the stack?
If not, how is a global SID after teh replication SID understood?
Or is a replication SID implicitly also a binding SID, replacing the 
rest of the stack no matter where it is in the stack?
    In which case it is implicitly effectively last?
Given taht a replication segment is qualified to a node, what happens if 
there is more than one in a stack?  Is it ignored when it hits a node it 
does not apply to?

Do I believe this can be made to work?  Yes.
But I can not understand how the WG could adopt the work with its 
current lack of clarity.
And this appears to me to be fundamental enough stuff that it can't be 
left to documents in other WGs.  It seems central to the definition and 
processing of replication SIDs.


Yours,
Joel - speaking as a participant