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

Joel Halpern <jmh@joelhalpern.com> Thu, 15 August 2024 15:02 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 24FA7C14F5FB; Thu, 15 Aug 2024 08:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.807
X-Spam-Level:
X-Spam-Status: No, score=-2.807 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=joelhalpern.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 trsWawgIn1cu; Thu, 15 Aug 2024 08:02:37 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEBCC14F615; Thu, 15 Aug 2024 08:02:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Wl7dm51jmz6Gsw7; Thu, 15 Aug 2024 08:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1723734156; bh=NuHNCIpQOCoZkUGeVvt3XT1owBigcOWrZ9H+z6edYzI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Atz8pphIgw7/O5FtNlAE7qXrEir8hDZZtl3cOVKD9U3bHWuF7exhi7uTcpJIdinMH 5erTR70Tt2H5AY2T69kWu0ja5ZGDBAR5Y0BmLpVO3RC1tR1D1miPMn25cJ96tT7CA6 qrEZZyNd2bUMUHb7+C28HPHnZkM7HiKng3f0xvEk=
X-Quarantine-ID: <c0Y9sGW7SFAI>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.20.161] (unknown [50.233.136.230]) (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Wl7dj13vCz6HC6k; Thu, 15 Aug 2024 08:02:32 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------K1qhU5WpIaJm3hJrRWdwHc4u"
Message-ID: <10125247-e14f-4dfe-b044-3c2e69e85095@joelhalpern.com>
Date: Thu, 15 Aug 2024 11:02:31 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: 韩柳燕 <hanliuyan@chinamobile.com>, draft-dong-spring-sr <draft-dong-spring-srv6-inter-layer-programming@ietf.org>, "Alexander.Vainshtein" <Alexander.Vainshtein@rbbn.com>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
References: <PH0PR03MB63005B338D8408CAC04A03FFF6B42@PH0PR03MB6300.namprd03.prod.outlook.com> <74e09326e43c439baf7765e97cc3d1f7@huawei.com> <PH0PR03MB63001BB4EFE06907957FB08BF6B52@PH0PR03MB6300.namprd03.prod.outlook.com> <e4c49d087ae142a2b9496305b3824c42@huawei.com> <2b0566bdd61f1c4-0001e.Richmail.00002062256900413234@chinamobile.com>
Content-Language: en-US
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <2b0566bdd61f1c4-0001e.Richmail.00002062256900413234@chinamobile.com>
Message-ID-Hash: 7BGO2F5CS2CKNRYLIDCZW42XH7DT2NQZ
X-Message-ID-Hash: 7BGO2F5CS2CKNRYLIDCZW42XH7DT2NQZ
X-MailFrom: jmh@joelhalpern.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: "spring@ietf.org" <spring@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: My question at the mike aboutdraft-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/6CWnUZ19ds3VRIC4szRnqaWViqM>
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>

Is there an assumption that some other monitoring exists so that there 
is knowledge of whetehr the link is up to control advertising the new 
adjacency SID?

Yours,

Joel

On 8/15/2024 6:32 AM, 韩柳燕 wrote:
>
> Hi Sasha,
>
>
> Thanks a lot for your question at the meeting and via the email 
> discussions.
>
>
> I would like to add some clarifications. The new SRv6 behaviors does 
> not require IGP based link discovery and advertisement for the 
> underlay connection between the two endpoints, which is needed for 
> End.X behavior. It is more adaptable to the network situation and has 
> application advantages. Because for large networks, the nodes at both 
> ends may span different metropolitan areas networks or even backbone 
> networks, and may not be in the same IGP domain due to the limited 
> size of IGP. The new SRv6 behaviors in this draft do not require IGP 
> to be enabled as the control protocol between the two end nodes of the 
> underlay link and doesn't require this link to be visible in L3 topology.
>
>
> Best regards,
>
> Liuyan
>
>
>     ----邮件原文----
>     *发件人:*"Dongjie \\(Jimmy\\)" <jie.dong=40huawei.com@dmarc.ietf.org>
>     *收件人:*Alexander Vainshtein
>     <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>,"draft-dong-spring-srv6-inter-layer-programming@ietf.org"
>     <draft-dong-spring-srv6-inter-layer-programming@ietf.org>
>     *抄 送: *"spring@ietf.org" <spring@ietf.org>
>     *发送时间:*2024-08-05 11:38:21
>     *主题:*RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming
>
>     Hi Sasha,
>
>     Thanks a lot for your comments during the SPRING session and in
>     the follow-up mails. Please see some replies inline with [Jie]:
>
>     *From:*Alexander Vainshtein
>     [mailto:Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org]
>     *Sent:* Sunday, July 28, 2024 1:05 AM
>     *To:* Dongjie (Jimmy) <jie.dong@huawei.com>;
>     draft-dong-spring-srv6-inter-layer-programming@ietf.org
>     *Cc:* spring@ietf.org
>     *Subject:* Re: My question at the mike about
>     draft-dong-spring-srv6-inter-layer-programming
>
>     Jie,
>
>     Lots of thanks for your email.
>
>     First, I would like to apologize for not responding to your emails
>     earlier.
>
>     [Jie] No problem, it is always good to know your opinion no matter
>     early or late:)
>
>     I think that there is a certain mismatch of terminology that have
>     resulted in misunderstanding.
>
>     [Jie] I also realized this, and have checked with my colleague who
>     is closer to the implementation.
>
>     In my (and, AFAIK, relatively common) terminology frames received
>     from a Layer 2 logical interface are disposed based solely in
>     their L2 header. (In the case of Ethernet this would include
>     Destination and Source MAC addresses  and zero, one or two VLAN
>     tags - but not the "true" Ethertype that follows these tags. Other
>     L2 media uses similar arrangements). I.e., the node that receives
>     Ethernet frames from what it considers a L2 interface cannot
>     differentiate between, say, IPv4, ARP,  IPv6 and MPLS.
>
>     [Jie] Agreed, although to my understanding MPLS sits between layer
>     2 and layer 3.
>
>     It is the ability to differentiate between different protocols
>     based on the "true" Ethertype and, say, look up the Destination
>     IPv6 address in the appropriate FIB (which is required for SRv6)
>     that makes an interface a  L3 one from my POV.
>
>     [Jie] Agree that for an interface to process SRv6 packets, it
>     needs to be associated with some L3 functionality. While it does
>     not need to be a full  L3 interface which is visible in the
>     routing topology. In other word, the L3 adjacency is better to be
>     avoided. We can add some clarification in next update.
>
>     Regarding your concern about L3 interfaces involving adjacencies,
>     I also think this is unfounded. It is quite easy to make an IGP
>     adjacency unusable for normal IP forwarding by assigning maximum
>     cost to the corresponding  link -but using Adj-SIDs allocated and
>     advertised for such a link in SR-TE policies that are set up by
>     the appropriate controller.
>
>     [Jie] The primary goal here is not about how to make an IGP
>     adjacency unusable in IP routing, it is about how to avoid the
>     challenge and cost of  establishing IGP adjacency between two
>     remote endpoints (they can even belong to different IGP domains).
>     As since the underlay interface and path can be created/deleted
>     dynamically, adding such link using Adj-SIDs to IGP would also
>     impact the protocol stability.
>
>     Thus it would be beneficial to distinguish it from the L3
>     Adj-SIDs/End.X SIDs in SPRING, and its advertisement can also be
>     separate from the control  plane mechanisms for Adj-SIDs/End.X SIDs.
>
>     Hope this helps to clarify the intent of this effort.
>
>     Best regards,
>
>     Jie
>
>     Hopefully these notes will be useful
>
>     Regards,
>
>     Sasha
>
>     Get Outlook for Android <https://aka.ms/AAb9ysg>
>
>     ------------------------------------------------------------------------
>
>     *From:*Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org>
>     *Sent:* Saturday, July 27, 2024 7:59:30 AM
>     *To:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>;
>     draft-dong-spring-srv6-inter-layer-programming@ietf.org
>     <draft-dong-spring-srv6-inter-layer-programming@ietf.org>
>     *Cc:* spring@ietf.org <spring@ietf.org>
>     *Subject:* [EXTERNAL] Re: My question at the mike about
>     draft-dong-spring-srv6-inter-layer-programming
>
>
>     Hi Sasha,
>
>     Thanks for your question at the mic. Please see some replies inline:
>
>     ________________________________________
>     From: Alexander Vainshtein
>     <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>
>     Sent: Saturday, July 27, 2024 5:27
>     To: draft-dong-spring-srv6-inter-layer-programming@ietf.org
>     Cc: spring@ietf.org
>     Subject: [spring] My question at the mike about
>     draft-dong-spring-srv6-inter-layer-programming
>
>     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
>
>     [Jie] The interface of the underlay link is not L3-capable, while
>     it still can have some packet processing capability. You may
>     consider it as a layer-2 logical interface.
>
>
>     * 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?
>
>     [Jie] Similar to what I said above, the receiving interface is not
>     L3-capable, while it can receive and process the packet properly
>     in layer-2, the inner L3 packet header can be processed by the node.
>
>
>     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.
>
>     [Jie] As described in the draft, making it an L3 adjacency between
>     the two endpoints is both challenging and unnecessary. And
>     operator does not want this link to be visible in L3 topology.
>     Thus regular End.X SID does not meet the requirement here.
>
>
>     Hope this help to answer your question.
>
>     Best regards,
>     Jie
>
>
>     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 tospring-leave@ietf.org