[spring] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming

Ketan Talaulikar <ketant.ietf@gmail.com> Fri, 26 July 2024 21:47 UTC

Return-Path: <ketant.ietf@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 D0662C1519AF; Fri, 26 Jul 2024 14:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_BPBvbZl-NN; Fri, 26 Jul 2024 14:47:40 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB53C1CAF49; Fri, 26 Jul 2024 14:47:40 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a6265d3ba8fso188962066b.0; Fri, 26 Jul 2024 14:47:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722030459; x=1722635259; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MrwU2dYWa7GA+2tT8OAzFX9Ei/hhKd3ny4mzkp13Z0w=; b=VpMBqf+cNtyKbgkqMVVBTo7TL2ttq9ZTOY/zGTOJKGbKxToL5Uy/4zYK1Hcr2kzyS7 /ieqv6a+PeT851KiabmQhcSSbZfFY/gvCToLAm9CbfzykyjRVuBsnMnV6k7TBEZ66ISP huTPyB0pu75eLB7eQqItj5vv3Rlw68WjwnzGPE8QzIoCqkt5DXwm0q+vf3kzBezSzBgj go8AqtnjZSR6w+3jX8UhqMECSigZsSsdtNgKbGO/MdWfOUpG/IpjkpzUo3P4XracuJaZ dMsQ1GRRh4XGTWCXq+s0lSv2/xAV/QVANtIaW2ziN49H2u6WwDJdyxjhCH/9OEb6M4DP P9YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722030459; x=1722635259; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MrwU2dYWa7GA+2tT8OAzFX9Ei/hhKd3ny4mzkp13Z0w=; b=gG8VHLDZOsjlQW1AmnsCsiRxvpVlfxz+kqtIugds1gAFtWezjs87Efk3Sme6ewj6RA PakqAwHm3g0bsFjjgDnS3uooPN0yDdmF3uXhaq5HO+uy+r1UjsncpCIl5KfGNbufmVUy OxY7alTL43vQa6S/HYxj8fQMRnusm/wwvueFjATn+cV8RiJV7MxiuEJlGVZxqQf7XAuc QYISEzyn5EgT5On3FF7kTGXAhQ+qmkLHtjG87tOo8c3S+ZlotBqaC9hwOZbqZf3XyT1t h1oejETxy9cHIYSbW0Vv3Dzt+c9m3/KE3fA7G4WVOiAkwY0TAEmUUqJcBbqB5SwM5SOo YzQg==
X-Forwarded-Encrypted: i=1; AJvYcCW4i7rjGfT7tJgl9s2ppSXx/t60+qbF7+xZjVxyeVUdVNFlXtTOjMs8EVdT3LB1u39Mqljyml2Gtbuoq3gR3ao=
X-Gm-Message-State: AOJu0YyGVuRPSYHlMXd7NnkBF2IZH0ap0bQ+1KQQtnBZl9gHvktPUlVX MZUzfgcq0mrV+CUhYu5CCe565B3jmROdz5jog7lzSG0F0ZLH0Oq0uhkAveq8/zkzq9HJ4AuvdUx iu+/Sbu6K06hsyy49Dzyl+g3psZkYXLVnUqAEHg==
X-Google-Smtp-Source: AGHT+IFb11OcxLPt3fjviR8K06y//5RrfoxQw2gD3EB/f5LHY2+lM2xZ1UeW7FvnsPS9Bk0io0YRyeG8eNCdhsAmMJg=
X-Received: by 2002:a17:907:d8c:b0:a7a:a89e:e230 with SMTP id a640c23a62f3a-a7d400a5ff2mr44261466b.30.1722030458419; Fri, 26 Jul 2024 14:47:38 -0700 (PDT)
MIME-Version: 1.0
References: <PH0PR03MB63005B338D8408CAC04A03FFF6B42@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB63005B338D8408CAC04A03FFF6B42@PH0PR03MB6300.namprd03.prod.outlook.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Fri, 26 Jul 2024 14:47:27 -0700
Message-ID: <CAH6gdPyA9W-01NmHXKr=Ro7fmWyy97c1zVpjez67hV8cwrvr1w@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c442aa061e2d75d5"
Message-ID-Hash: J2ZTHH4NFQC54WDYFGK5XDWADYBUVMBK
X-Message-ID-Hash: J2ZTHH4NFQC54WDYFGK5XDWADYBUVMBK
X-MailFrom: ketant.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "draft-dong-spring-srv6-inter-layer-programming@ietf.org" <draft-dong-spring-srv6-inter-layer-programming@ietf.org>, "spring@ietf.org" <spring@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Wub6xk4pHGU-_lTn_9gC7WJqa3w>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

Adding to what Sasha has said, RFC8986 that has specified End.X (refer
https://www.rfc-editor.org/rfc/rfc8986.html#section-4.2) also allows for
the same to be used for the underlying L2 bundle member links as well.

To me, the L3 interface with optical sub-channels under it, seems similar
and makes me also wonder (same as Sasha) about why End.X is not sufficient.

Thanks,
Ketan


On Fri, Jul 26, 2024 at 2:28 PM Alexander Vainshtein <Alexander.Vainshtein=
40rbbn.com@dmarc.ietf.org> wrote:

> Hi all,
>
> Just repeating the question about the draft
> <https://datatracker.ietf.org/doc/html/draft-dong-spring-srv6-inter-layer-programming-08>
> I’ve asked at he mike at the SPRING WG session today.
>
>
>
>    - Suppose that there is an underlay link between a pair of IP nodes
>    that is not “visible in he L3 topology”. To me this means that there no
>    P-capable (logical) interfaces associated with the endpoints of this
>    underlay link
>    - Suppose further that one of these nodes (the upstream one) allocates
>    and advertises an SID with End.XU behavior for this underlay link
>    - The upstream node receives an IPv6 packets with the tops SRv6 SID on
>    it being the End.XU. It strips this SID (this the common behavior of all
>    End-like SIDs) and send the resulting IPv6 packet across the link to the
>    downstream node/\.
>
> Now the question: How should the downstream node process the received
> packet if its local endpoint of the undelay link s not associated with an
> IP-capable logical interface?
>
>
>
> If the endpoints of the underlay ink are associated with L3 interfaces in
> both nodes, the link becomes visible in L3 topology, and a regular End.X
> SID can be allocated and advertised for it.
>
>
>
> Hopefully this clarifies my question.
>
>
>
> Regards,
>
> Sasha
>
>
>
>
> *Disclaimer*
>
> This e-mail together with any attachments may contain information of
> Ribbon Communications Inc. and its Affiliates that is confidential and/or
> proprietary for the sole use of the intended recipient. Any review,
> disclosure, reliance or distribution by others or forwarding without
> express permission is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately and then delete all copies,
> including any attachments.
> _______________________________________________
> spring mailing list -- spring@ietf.org
> To unsubscribe send an email to spring-leave@ietf.org
>