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

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Tue, 20 August 2024 17:17 UTC

Return-Path: <alexander.vainshtein@rbbn.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 DA15CC1524DC for <spring@ietfa.amsl.com>; Tue, 20 Aug 2024 10:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 kE7KvRGQaLQv for <spring@ietfa.amsl.com>; Tue, 20 Aug 2024 10:17:53 -0700 (PDT)
Received: from usb-smtp-delivery-110.mimecast.com (usb-smtp-delivery-110.mimecast.com [170.10.153.110]) (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 C607EC17C882 for <spring@ietf.org>; Tue, 20 Aug 2024 10:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20230413; t=1724174272; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VSyRnypiVdMkTSF3L3JpwnKrqlUtlCEEbEYM5qai8b4=; b=nzirDKB86/S0RtxaeVdl7CfF/tHqMyYlFAYKs6Ni1gL/27+Gn+Rd217bNSbhsPaNV3sEjq X+Q1oiVFkQk/52T/ZMWFndLavz2q2PKdM+yPFzIyzmMUIDSKwq+bTOG/hgW+K1Gdg2SGXX 5GvALqtKEvcRVgJE8zsBG+MH7pH/je0=
Received: from SJ2PR03CU001.outbound.protection.outlook.com (mail-westusazlp17012032.outbound.protection.outlook.com [40.93.1.32]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id usb-mta-10-vmAw9BmFNimH2yoyRZ3tcw-2; Tue, 20 Aug 2024 10:17:47 -0700
X-MC-Unique: vmAw9BmFNimH2yoyRZ3tcw-2
Received: from PH0PR03MB6300.namprd03.prod.outlook.com (2603:10b6:510:e2::5) by CO1PR03MB7915.namprd03.prod.outlook.com (2603:10b6:303:270::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.21; Tue, 20 Aug 2024 17:17:43 +0000
Received: from PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::a48b:db16:775a:4a16]) by PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::a48b:db16:775a:4a16%4]) with mapi id 15.20.7875.019; Tue, 20 Aug 2024 17:17:43 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: 韩柳燕 <hanliuyan@chinamobile.com>
Thread-Topic: [EXTERNAL] [spring] Re: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming
Thread-Index: AQHa7v57iaL9Nq+kBUe69uc6BIjOa7IwaQLw
Date: Tue, 20 Aug 2024 17:17:43 +0000
Message-ID: <PH0PR03MB63001B24B67BECBC60402456F68D2@PH0PR03MB6300.namprd03.prod.outlook.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>
In-Reply-To: <2b0566bdd61f1c4-0001e.Richmail.00002062256900413234@chinamobile.com>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR03MB6300:EE_|CO1PR03MB7915:EE_
x-ms-office365-filtering-correlation-id: 5ee79e98-50b6-46d4-8acd-08dcc13c00ae
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|38070700018
x-microsoft-antispam-message-info: yr7FZRPYmwesNto/igdMwapV9lAHWZ8VLuDEJSRwloqeugKU7ahXDp8cSlecv9DUOPH2xJXkOQwZyJ/AoGC8SaWSLyUpgGI81tBwtb3wW36nL7vhiOZKzINRlgPEUmwm6/k8R82TvnLB5k5cf5lwUkv91Poir/FGOatReikiB6IIdSvFljH5F3DIE4a7TMEEukv3AmY/qL/jxVs62TCS/aHvyDE8RNMXeY/+/sU1dusuuXcsFLV+sARg2S9aoCXcsPuKx5eu5szeyonkD5ihcMYRYFWG8mRQoTLBxdSk3LGC73yWFRH+0MWqEUCoXWH1czgwUvViIzugUcZJDofLy+jvmYrHhfIqVuLlWv3ditzFWaBKccC2IkAKSntHWlLc+Gtt69ZNWkG0enJnmgmiZyN0uQlSI49uMvaQ6fF68u9i1RRwtQ4Oi6fkNddO1KGmuCfYlJwrVwvp4SA2+L75PvlEoG8ryZcNT+vQUhv9dNBh3i3kbs3Kt3NTXg6uNwGFYoTXl7udm8hHx41FjrDgDPPjGBNDq99Wl1s8F983Pacpm31JJoHs+w7obxJg8YoAI9g/t+3HbyocHZYlhLVvbSymS3GuET4uT4gpsNcKH95/ZDQkpuoGPlda9HoAHnsdIZwT+P6sprS1Bh4OC/yYudOrsfxLQoL+KSkWEV5xqJ3b74vRyUpvl06SkmVLoPILK6NRbz4fn9FD/EfHH5T8nRdOZtcqbGvdtDqA8Jng89HdBLEEL+p22Z1IWOVa+qL39/v1S8Hgx+jt4T9gzoI8N/IXLvg8k5J8sfGh4ffWX+/1gmyVop5i5hKdTw+2bfb//JQ59Xt6X15VXDI+WcieA+Chv8hgjhZQH313BHb1K3yiGfVOBQ+AmHZfYugAPn05JW4U7s9p1cQxqSA07caXDO5icPuiks7Unua7d59yzeIMuRdA97anGMioKwCmCtc46E9gcNccyU6gpE9LJM5/PKTeMH5FwQJMaZ/rirBu0IDJnsFG2bX6vjvZhXsgv0CUqCdSoBSbmAB0zxblf02egSgp6+VMiJojAnXV19B7QJms9KZY6rbHK9PZqN+DuyPV6D37ooINyXormdugz7ZS6+JYQMTy+Ra8tNoCZuTkS7AyTelHCEvSvpro/rEeRwDZudXMBGS1+TxelEdsJyL8qxy425LE0/97ytpGstKmxmz8nGgRqo7yT71Rt+4lg30t0q0j84RaUVepwpl+f4kPX0MFDtuXAyUE8/l5HMpQ96BXcaKFu130iXUsQW27VlmZNFlseovnbqr1wXqYTNPwE3euR0NrIKlpZRxvQp/HA4Iu6Re2x5dqa1qdrguQnJynZRCGebcoAfALGTNsSvRjezmQrGzGYy4gWUjr1BR/a8A=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR03MB6300.namprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(38070700018);DIR:OUT;SFP:1102
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Fa7HJ5aK1KuoGSxKm/9lViYmYDoW9iwT2gf730ZMiqQDNL2OhMWqZHeLLOVu4Rpy5jUh2qfigOBQhdncLEuADKdmslCR+t9spCA1pxh2r5JtPd0MRo9Zu50GNk+KL9xORgEOFk3Xv20QKsyiZ39FRLi0L4Xn5E3odvM2re6fWFTpfTgg6YPFiitNuKWYkQjunj/GHBVnfTkizwNclmS5WZSL+rkvpk7ZQAPPdjQM0aHanYJ9Kr1W355UzqLmTttyWH/91Mp2ikJqsmVnu8NjKfp9PZL72W0XBamMx7o3p4nnsEKnzfAl0GgdR4jaPTOjELdVekrirGaVw6mDDQqQDNdU42iA1OX7XtsF2nWr2gsNDiQtz4vxD1uZYmBlD3+xyPjEXAH/uW8No8Nj62ZHB6C/57IRUCa3vppbWnuQzyYzAImPBJyDj9KfGCS6RlzhwtlfvUCKRgjLtB3p/3hLYYCsBxSM2BhWNhWsnrHlkk/txfEN/VguQevM602ugHmPNLVUci3GeYT5lCkB/E2/eM0AsUyeojcIMF0NRmkNuuVKR7/i7HWaz5PLVwP5q8A6NUoheNdGXESp1YSOnkXM5lj/QNJrrBRcGcCdBaUvgLm6Cqnwnz1d3l67m67ogocg35/83/Lp7h5kMOE6LYnCQuoPAqqSHQwS9fyhj010mYNpCRBVLXFiAX0EbMpncq5ntib6V7i/4vwcvHlKSDft35kFZ/sOna9tcUHT0d00NK+cINraJQNLCO0mrVlcJ+nMuGvzn0dGlnVgxUhujZlR2QvHMept4T8PCEZVnJG5kvLR3Yf5AcVXp9eEZMpaB+psdGvASFvTKTCZXEX0te1j+3xKC2qQqUV2FtzLrPcj9DCv3k98fhYWS/I7R/P90mzARbmDCUSdAktoIYDeLDQ0UQFL4+2wguzrhNjlWUzGF8Roq8zqy96FBvEpFxf2H+sNvEkIgYFg4YD88fCQwiNc9ny/4o7jt0sQ5OOL5W3yv4TzVKvuyJB8RSZnsFWkNwnOeZ/3jsvGFrcuAAT9xDxTh2JfQg4AMC5WlGOJNcbvO8Ac71bZD7+q06+BvrwwsYHXu3RS9+XpzXN9VhJgunmfk/M06VXQFToK3W+o+XYu4+IaQI1l1aRt126PMl26h9+rg8tpP+6nrVTjtMs4iq4gXz1SV2L1N9rIl8SkarbB+/hkSvpIiF/69nwwe/8vM7fLTGqa54eeez6KwnAOZGoPAV7rgRuy/D105033qIvh6VJ099r7n/u6UHXGzDteFqS2tlcflPzDOpwpNHONvOCGRmBAWt5iOWHbBXa1bebEw+c+4NO5GtvdWyB+JHQGDImjQN0e/mw2YSc+D/sXxGQmlMYH3UvuRrmdy6VtsiQWYg6ovoKH/YLyIMTo8+GALnZ4SPlXQHpkeqEKhKWLQI2s8rMwKF6xqyMGXhn0SNiLic+gSsLht9JKT/QDbpnGU9KPyl3k+skW0Hd2pVTgaZDM0KeJFqPgwJpQcv2AW3TZGZcNpakelJHKE3Y4713yM1IxWgwxMCABvFappYgWOwEmuL20YVv7Csjlig/e3YFoY9QBnxIUpyzldNXyh0c0i0KX
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6300.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5ee79e98-50b6-46d4-8acd-08dcc13c00ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2024 17:17:43.3368 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Z/3WAqY7HiXUHLfyn6pptKVCbt2xBk1wOXmtYf2KzzUPQ7s0qHQ9VTQKRYRF4K3PmpzyNPSeHSAotdLDFcGkNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR03MB7915
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_PH0PR03MB63001B24B67BECBC60402456F68D2PH0PR03MB6300namp_"
Message-ID-Hash: 7XQYLXRV2QIRMURJ3IKMO2UHJE65PGLP
X-Message-ID-Hash: 7XQYLXRV2QIRMURJ3IKMO2UHJE65PGLP
X-MailFrom: alexander.vainshtein@rbbn.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>, draft-dong-spring-sr <draft-dong-spring-srv6-inter-layer-programming@ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: [EXTERNAL] 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/WXJmO1PWdFQcT6KyiIXEPmeF4mU>
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>

Hi Liyuan,

My apologies for a delayed response.

I have looked up Section 4.2 of RFC 8986<https://datatracker.ietf.org/doc/html/rfc8986#section-4.2> (that defines End.X behavior) and it contains the following statement:

When the End.X behavior is associated with a BGP Next-Hop, it is the SRv6 instantiation of the BGP peering segments [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>]

I.e., End.X behavior can be decoupled from IGP adjacencies.

Hope this helps.
Regards,
Sasha

From: 韩柳燕 <hanliuyan@chinamobile.com>
Sent: Thursday, August 15, 2024 1:32 PM
To: 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>
Cc: spring@ietf.org
Subject: [EXTERNAL] [spring] Re: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming


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\\)<file://(Jimmy/)>" <jie.dong=40huawei.com@dmarc.ietf.org<mailto:jie.dong=40huawei.com@dmarc.ietf.org>>
收件人:Alexander Vainshtein  <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>>,"draft-dong-spring-srv6-inter-layer-programming@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programming@ietf.org>" <draft-dong-spring-srv6-inter-layer-programming@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programming@ietf.org>>
抄 送: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto: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<mailto:jie.dong@huawei.com>>; draft-dong-spring-srv6-inter-layer-programming@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programming@ietf.org>
Cc: spring@ietf.org<mailto: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<mailto:jie.dong=40huawei.com@dmarc.ietf.org>>
Sent: Saturday, July 27, 2024 7:59:30 AM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; draft-dong-spring-srv6-inter-layer-programming@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programming@ietf.org> <draft-dong-spring-srv6-inter-layer-programming@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programming@ietf.org>>
Cc: spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto: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<mailto:Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>>
Sent: Saturday, July 27, 2024 5:27
To: draft-dong-spring-srv6-inter-layer-programming@ietf.org<mailto:draft-dong-spring-srv6-inter-layer-programming@ietf.org>
Cc: spring@ietf.org<mailto: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<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.