[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
- [spring] My question at the mike about draft-dong… Alexander Vainshtein
- [spring] Re: My question at the mike about draft-… Ketan Talaulikar
- [spring] Re: [EXTERNAL] Re: My question at the mi… Alexander Vainshtein
- [spring] Re: My question at the mike about draft-… Dongjie (Jimmy)
- [spring] Re: My question at the mike about draft-… Dongjie (Jimmy)
- [spring] Re: My question at the mike about draft-… Gyan Mishra
- [spring] Re: My question at the mike about draft-… Alexander Vainshtein
- [spring] Re: My question at the mike about draft-… Dongjie (Jimmy)
- [spring] Re: My question at the mike aboutdraft-d… Joel Halpern
- [spring] Re: My question at the mike about draft-… Gyan Mishra
- [spring] Re: My question at the mike about draft-… 韩柳燕
- [spring] Re: My question at the mike about draft-… Dongjie (Jimmy)
- [spring] Re: My question at the mikeaboutdraft-do… Joel Halpern
- [spring] Re: My question at the mike about draft-… Gyan Mishra
- [spring] Re: My question at the mike about draft-… 韩柳燕
- [spring] Re: My question at the mike aboutdraft-d… 韩柳燕
- [spring] Re: My question at the mikeaboutdraft-do… 韩柳燕
- [spring] Re: My question at themikeaboutdraft-don… 韩柳燕
- [spring] Re: [EXTERNAL] Re: My question at the mi… Alexander Vainshtein
- [spring] Re: [EXTERNAL] Re: My question at the mi… 韩柳燕
- [spring] Re: [EXTERNAL] Re: My question at the mi… Alexander Vainshtein
- [spring] Re: [EXTERNAL] Re: My question at themik… 韩柳燕
- [spring] Re: [EXTERNAL] Re: My question atthemike… 韩柳燕
- [spring] Re: [EXTERNAL] Re: My question atthemike… Dongjie (Jimmy)
- [spring] Re: [EXTERNAL] Re: My question at the mi… 张乃晗(联通集团科技创新部)